User:Terrye/A phpBB Use Case Discussion

Analysis by function
The following analysis is based the web requests aggregated across all nine forums available to the OpenOffice User Community (by analysing on week's worth of Apache logs). These patterns are consistent across all ten forums, as well as for the VirtualBox forum which I also help to run and have analysed. User-agent:* Crawl-Delay: 1 Allow: /index.php Allow: /viewforum.php Allow: /viewtopic.php Disallow: /
 * As an indication of volumes, we processed just under one million PHP transactions last week on OOo with the breakdown as shown in the piechart.
 * This breakdown is in terms PHP requests, but only the breakout segments on the right are directly due to a user clicking in the a View Topic or similar link.
 * If I focus on the 56% of PHP webpage (HTML) requests and break those out in percentage terms totalling 100, the viewtopic function dominates the work load (77%), with the other main types being viewforum (8.7%), ucp (mostly logons) (5.2%), board index (3.2%), search (3.0%), posting (2.1%), and the rest are crumbs.
 * The other 44% of the URI requests are the embedded requests to load style sheets and images such as avatars and embedded pictures. I haven't included the cache check requests (where the browser cached version still valid), nor any of the other static requests such as the GIF and PNG 'furniture' that generate another couple of million logged the Apache GET requests.
 * The web bots were responsible for over 50% of our viewtopic and viewforum hits. MSN was the biggest offender here generating more requests than all other bots combined, which is ironic as we get almost no references from MSN, but quite a lot from Google. (In the case of the VirtualBox forum the bots generated over two-thirds!). Hence it is essential that you properly configure your robots.txt if you want to minimise the impact on your forum.  I would suggest the following as a starting point but increase the Crawler-Delay to 3-5 sec if you are running on a shared Hosting Service.
 * In general the bots only download the HTML content from viewtopic and ignore the other webpage furniture. Hence the proportion of furniture requests will increase slightly if your site isn't being widely indexed.
 * Modern browsers do a lot of local caching on the end-user PC. By analysing where interactive requests are not downloading page furniture, I can estimate these local browser cache percentages: for the top avatars (~85%), top images (63%), javascripts (81%), CSS (81%).
 * However I do see multiple phpBB users per IP (typically where these users are logging in via a corporate or ISP proxy), and from an analysis of posts which are identified by both userID and IP, I can get an estimate of how frequent multiple users per IP is. What I found really surprised me: 75% of posts were made from shared IPs in the last 10 days.  These proxies also cache static files and therefore skew these stats.  If the majority of your user population is home users that I suspect that your percentage of proxy hits will be smaller.

Use Cases
Any performance tuning analysis is best grounded in a hard target system to provide the instrumentation data. My analysis above was for forums running on a dedicated server in the case of OOo and on a VM in the case of VirtualBox. In the case of a product such as phpBB, we need to identify typical use cases and I focus on three: a shared web service, a hosted virtual service (also known as a virtual private server) and a dedicated hosting service. Note that I've used Linux terminology in the following descriptions, but the equivalent MS stacks based on W2003/2008 and IIS are also commonly available. I also use the description administrator in the context of the person who buys the service from the HSP and runs the phpBB service, to differentiate from the end-users who will ultimate access it through the Internet.

In these cases I often use the term contention ratio, and what I mean in this context is the number of users or services which share the resource. If you are running your service on a dedicated server then you full control over the entire machine's resources. If you are running your service on a shared web service along with 400 other users then when an end-user wants to access your phpBB instance, the phpBB software has to contend for machine resources such disk, memory and I/O operations with 399 other applications. OK 300 might be doing virtually nothing, but if you are unlucky then 20 or so might be using the server heavily. The higher the contention ratio, the worse this competition gets.

A Comparison Discussion
The differences between the HVS and DHS are largely a question of degree. The main differences between configurations tuned to these two cases are really limited to the Apache MPM settings and the MySQL my.cnf settings to ensure that the database can fully make use of the extra memory resources to improve internal cache hit ratios and limit physical disk I/O. Except for these two factors, the phpBB tuned configurations are quite similar and the overall issues are the same. On the other hand, the SWS installation and scenario is very different:


 * You have no control over the Apache (or IIS configuration)
 * You have little control over the PHP engine or its tuning. The PHP configuration will largely by what is defined in the system php.ini file and build as shown in a phpinfo report. It unlikely that any form of code or variable caching will be available to you.
 * Because of the high administrator contention ratios and relatively infrequent page loads, the file system cache hit rate for all the files in a first page load will typically be low and therefore require a lot of physical I/Os to retrieve the data from disk (though the hit rate might improve for subsequent similar requests as long as the inter-page rate is less than a minute or so). For example, executing a single viewtopic.php requires loading and compiling 650Kb of PHP source from 26 separate files, as well a dozen or more data files from the cache directory. The main latency here isn't from compiling the 650Kb of source; it is all the HDD seeks needed at a worst case to read those 50 plus inodes and 200 odd data blocks. Worse, each separate file open as well as each read will cause a process reschedule / context switch (unless fully cached) before the next I/Os can be scheduled. If the shared service is on a busy server with active contention this could take tens of seconds.
 * The situation for the database functions is similar because the MySQL servers on such systems also have a high contention ratio and might be serving thousands of tables across hundreds of databases. In this scenario, the likelihood of good caching characteristics is low, so SQL queries will also tend to generate a lot of physical I/Os.

This situation is fundamentally different even for an entry level HVS with a 512Kb LAMP, as this is sufficient to install a PHP accelerator such as Xcache or APC.


 * With a standard phpBB application, a 8Mb code cache is sufficient to get a 99.5% hit rate on PHP code. (See Figure 1 for my background analysis).  More importantly (if you have stat checking turned off), this generates zero I/O. A 4Mb data cache is sufficient to cache all stored variables enabling the use of acm_xcache or acm_apc to remove the physical I/O associated with stored variables that would otherwise be stored in the cache directory.


 * In other words a HVS with PHP code and data caching enabled will effectively remove the bulk physical I/Os which cause process rescheduling. The main delay now becomes the execution of that 20K lines or so of code needed to render the webpage, plus any the delays in executing the uncached SQL queries.


 * The VM's file system caches that are dedicated to your application mean that most writes are write-though and non-blocking and therefore do not impact on throughput.


 * A 512Mb LAMP would probably be best configured with an MPM worker setup because of memory footprint. Despite the caveats in the Apache guidelines, this is fine for a single application LAMP setup.


 * A 512Mb LAMP has enough memory to allow a my.cnf that enables the indexes for a typical medium BB (say less then 50K posts) to be fully cached. Hot data rows will also tend to get cached so I/O will be limited to row retrieval only.

Hence the I/O rates for a SWS will typically be a order of magnitude greater than for a tuned entry level HVS at comparable request volumes, and the contention ratio for other services hosted on the server will be greater. This is why an SWS can typically take an order of magnitude or more longer to process a phpBB page request and why its throughput is accordingly lower.

An HVS RAM of 512Mb or more allows some optimisation of the MySQL database configuration to improve the effectiveness of MySQL caching for all but the largest forums. With high cache rates, the effect of the HDD as a single resource constraint falls considerably and the true concurrency of the web service increases. Sustained throughputs of one page per second can be considered.


 * Main Article: I/O Performance Impacts on phpBB installations

Notwithstanding this, a shared web service is an entirely practical option for a board which averages, say, one page view per minute or less. OK, so pages may be slightly slow to load, but this won't cause queuing problems at this request rate. If you use volumes rise much above this then you need to start considering a move to a hosted virtual service.