User:Terrye/Configuring a Shared Hosting Service for phpBB

This note provides guidelines for administrators on how to optimize phpBB to run on a standard LAMP-based shared hosting service. This type of service is offered by many Hosting Service Providers (HSPs), as given in this typical service description. It can provide a cost-effective solution for most small-to-medium sized forums. If you have a larger forum running phpBB on your own dedicated server, a dedicated VM or have chosen Microsoft IIS for your platform then you will need to refer to alternative articles in this series.

The phpBB installation instructions are adequate for a basic installation. However for those administrators who wish to delve deeper, you can often achieve a 2-4x response increase on your forum by following the instructions given in this article.

= The basics = Shared services have some standard characteristics that you will have to work within:
 * You will have no root access or ability to modify the system or the Apache configuration.
 * You will probably have no interactive access or ability to run cron jobs.
 * All of your access and scripts will run under your own account-specific UID. This will enable you to protect your data from other users, but also prevent you from accessing theirs.
 * You will have access to a PHP scripting environment but this will run under SuEXEC, SuPHP, or equivalent.
 * You will have access to one or more (typically MySQL) databases, and phpMyAdmin access to manage these.
 * You will have file based access to your file hierarchy, normally FTP at a minimum but often also SFTP.
 * The HSP will normally provide some administration console to set up your databases, email accounts, FTP access, etc..

Given this your ability to tune the system performance is limited to four aspects:
 * Using the .htaccess files to configure Apache handling
 * Using the php.ini files to configure the PHP interpreter's behaviour
 * Configuring the phpBB application itself
 * Doing regular database maintenance.

However before you begin, you really need some basic tools to help you to work access and work with the shared service:
 * An FTP/SFTP based browser. There are many 3rd party utilities which are available for Windows (see here) and your HSP might recommend one. On Linux and MacOS there is no point in using a 3rd party utility as this functionality is built into the standard file browser.
 * A reasonable editor which supports Unix line-ending text formats.
 * A developer toolset for your browser. I recommend using Google Chrome because the developer tools that you need are part of the standard download, however most browsers have an add-on pack which provides similar functionality, though the how-to details will vary slight from the description given in the following section.
 * If you want to do development or try things out locally before uploading to your web service, then you might wish to set up a local test environment on your PC. The easiest way to do this, if you are running Windows, is to download a standard free VM hosting application such as VMware or VirtualBox and a pre-build LAMP VM. If you are running Linux, then the easiest way is to install a standard LAMP bundle. However, this is a more advanced topic outside the scope of this article.

= Using Chrome to instrument your website response =

The main one that you will use in instrumenting website performance is the Network Panel. You can access this when visiting any website by typing Shift+Ctrl+i whilst viewing the page, and the screen snapshots show the display for the phpBB Community Forums Board Index. (The viewing options were tweaks to fit the report into two snapshots).



These were taken with an empty browser cache and if you look at the zoomed figures, then you will see that it took my browser some 5.97 seconds to download the 55 files comprising some 314 Kbytes needed to render the page. Revisiting this page later in the same session took some 0.92 seconds and this time nearly all files were already cached locally on the PC with only 2 files comprising 9 Kbytes needing to be downloaded. The user experience on these two occasions was totally different: on the first view the page was terribly sluggish and stuttered during loading; on the second it was a case of click-2-3-bang and the page was displayed. So considering why were these are so different gives a good insight into what you can do to tune performance.


 * The fastest resource to load is one that the browser has already cached locally. This is quick for the browser to do this and it also avoids network delays and server load of fetching the resource.  However the browser needs to know that it can safely cache a resource before it will do so and the mechanism for doing this is the interchange of request and response headers as part of the HTTP protocol between the client browser and the server, and specifically the Expires and Cache-Control: max-age parameters.  This article provides a more detailed discussion.


 * The next fastest method is when the browser and server exchange version information for each resource so that downloading can be bypassed if the locally cached version is the current one. Again the HTTP protocol enables this through the ETag and Last-Modified parameters.  This method largely eliminates network transfer delays, but the server must still be interrogated using this protocol and more importantly, if the resource is a dynamic resource that is generated by a script then the script must still be executed on the server before a response can be given.


 * The third method is to compress any outbound text data streams. Nearly all dynamic (and therefore not cacheable) content falls into this category and whilst compressing can add a few percent to the server CPU cycles, it will also reduced network volumes (and transmission delays) by a factor of three or so.

It is essential that you configure your server to best use of these features and avoid unnecessary and time-consuming requests to the server. You can use the Apache .htaccess files to do this.

However, even when you've set all this up, the server will still need to process the remaining static files and scripts, before returning the content. It is this processing delay which results in the lag that you can see for each transferred file. On executing any script on a shared service is a relatively expensive operation. In the case of phpBB this involves image activation of the PHP runtime system and loading all of the scripts and data files needed to execute the request.


 * So the fastest script is a script avoided by the use of a static file. Configuring .htaccess for phpBB describes one tweak which you can use to achieve this.


 * There are various configuration options within phpBB which allow you to tailor the package for different installation environments. Selecting the correct options here can make a considerable difference to the runtime overhead of a phpBB request on a shared service.

It's a good idea to use this tool and to capture a range of network timelines to establish a baseline before you start any optimisation activities, so that you can get a feel for the improvements that you are achieving.

= Putting it all together =

To keep this article manageable, the details on how the do these various configuration changes have been moved to the following subsidiary articles:


 * Configuring .htaccess for phpBB
 * Configuring php.ini for phpBB
 * Configuring phpBB for a Shared Hosting Service
 * Database maintenance for phpBB

The difference between getting all these configurations right and a set of non-optimum defaults can impact your users' perception of your board responsiveness by up to a factor of 4x. So if you feel the response of your default installation is unacceptable, try implementing some or all of these recommendations before considering upgrading or moving your shared service.