Any performance tuning analysis is best grounded in a hard target system to provide the instrumentation data. In the case of a product such as phpBB, the best we can do is to identify typical use cases. I summarise the three basic use cases under the abbreviations SWS, HVS and DHS. I’ve used Linux terminology in these descriptions, but the equivalent MS stacks are available based on W2003/2008 and IIS with similar performance characteristics. I also use the description “service-user” in the context of the person who buys the service from the service provider to contrast with the end-users who will ultimate access it through the Internet.
| Service Type | Share Web Service (SWS) |
| Typical price per annum | $50-250 |
| Service Description | Many users are co-located on a LAMP server in some Internet-connected datacentre with a private file hierarchy served through a common Apache2 and the ability to run PHP5 scripts and use a private MySQL database. Mail services and SMTP access are also typically provided. This type of service is the minimum entry service capable of hosting a phpBB installation. |
| Resources | The service provider might map 100-400 such service-user accounts onto a single rack-mounted quad server might serve, though some of the larger service providers load balance individual user accounts across a farm of servers. The service-user’s domain is DNS mapped onto a shared IP served by the server, with its Apache configured to map the user’s domain onto the users account and file hierarchy. |
| Access Models | FTP access to personal file hierarchy, phpMyAdmin access to MySQL, ad hoc access through PHP and CGI Perl scripts. Typically able to configure .htaccess but not php.ini. No SSH access; no cron or batch. |
| Performance Constraints | In the case of LAMP stacks, these types of shared services rarely use the Apache PHP module, but instead use CGI PHP via suexec or suPHP running in the service-user’s UID. They don’t employ cached based PHP Accelerator technology, though use of the Zend platform and optimiser is quite common. With such contention ratios, it is highly likely that a lot of program and data fetches will have aged out of memory caches and therefore generate cache misses and hard (physical) I/Os for both file and database stored information. The IIS equivalent has similar performance characteristics. |
| Typical Page Latency | The high percentage of cache misses mean that aggregate I/O latencies (together with the consequential rescheduling and context switches. These will often dominate page processing and therefore page processing times can be multiple seconds |
| Typical Volumetrics | The aggregate is rarely in excess of a few page views per minute (which can still build up to 10K per day. |
| Service Type | Hosted Virtual Service (HVS) |
| Typical price per annum | Typical costs range from $250-$1000 per annum. |
| Service Description | The service provider offers each service-user a personal VM instance, typically running a minimal LAMP configuration under an Enterprise VM solution such as Virtuozo, Xen Enterprise or VMware ESX. Hence the Apache2 instance, the PHP engine and MySQL instance all fall within this footprint. |
| Resources | The key service differentiators are the guaranteed RAM available to the guest VM, the contention ratio (that is how many VMs per host server) and resources such as disk capacity and Internet capacity per month. An entry level service might guarantee 200Mb RAM and have a contention ratio of 40:1 with the top end having say 1Gb RAM and a dedicated core. All of these VMs will typically share access typically to a SATA RAID-1 or RAID-5 array locally connected to the host hardware. A publicly registered IP address statically allocated to the VM is also common. |
| Access Models | The service-user is given root access to the VM typically through SFTP and SSH, as well as normal FTP and web access to a management console. The service-user has full configuration control over the guest OS subject to personal administration skills and service provider “reasonable use” guidelines. |
| Performance Constraints | Given the committed memory constraints it is still possible to configure a phpBB instance where the code is fully cached using a memory accelerator such as Xcache or APC as well as the phpBB cached data, and still have enough memory allocated to MySQL to guarantee all the board hot indexes are fully cached for a medium sized forum (say <100K posts) in a 256Kb LAMP VM.
Any data or page faults requiring physical I/O will still represent a major performance risk as the disk I/O capacity is share across all VMs |
| Typical Page Latency | ~ 1 sec for a tuned VM. |
| Typical Volumetrics | 60 web pages / min for a tuned VM. 5 web pages / min for an “out-of-the-box” phpBB installation on a default LAMP configuration. |
| Service Type | Dedicated Hosting Service (DHS). Here you have a dedicated server with full control over its configuration and use. |
| Typical price per annum | Around $1000 per annum for an entry level system, but anything up to $10K per annum depending on server specification. |
| Service Description | For entry level dedicated servers, the service-user has full control of the machine and its I/O resources to configure it largely as desired. Service providers typically have a number of standard system templates base on a number of LAMP configurations and Windows (2003 or 2008). Most service providers also provide console services to access backup and other shared services, and to provision the server at service start-up and in case of disaster. |
| Resources | One might say: similar to a VM but more of it and without the contention ratio. At a typical entry level, the service might comprise a dedicated low power dual core with 512Mb RAM and a single dedicated SATA, with a shared backup service. Adding extra cores, memory, I/O capacity, shared SAN access, hardware fail-over can all increase the capacity of a shared service at a commensurate increase in cost. There are also federated services using “cloud computing” models, though these aren’t relevant to the vast majority of phpBB uses. The key service differentiator is the guaranteed machine resource RAM and dedicated I/O, with none of the contention risks of a HVS approach. |
| Access Models | Largely the same as HVS. |
| Performance Constraints | Given the increased resources compared to a typical HVS it is straightforward to configure a phpBB instance where the code is fully cached using a memory accelerator such as Xcache or APC. Enough memory can be allocated to MySQL to guarantee all the board indexes are fully cached for a large sized forum as well as data cache large enough to largely remove database cache misses, and when they occur the dedicate I/O capacity means that the server can have predictable performance. |
| Typical Page Latency | <1 sec unless the board is overloaded. |
| Typical Volumetrics | 200-400 web pages / min for a tuned system. 20-50 web pages /min for an “out-of-the-box” phpBB installation on a default LAMP configuration |
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 my.cnf setting to ensure that MySQL can fully take use of the extra memory resources to improve internal cache hit ratios and limit physical disk I/O. Except for these the phpBB tuned configurations are quite similar and the overall issues are the same. However, the SWS installation and scenario is very different.
- You have no control over the Apache (or IIS configuration)
- You have no control over the PHP engine or its tuning. The PHP configuration will largely be 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 service-user contention ratios and relatively infrequent page loads, all the files in a first page load will typically all be file system cache misses and require physical I/Os to retrieve the data from disk, though the hit rate my improve for subsequent views of the same function as long as the inter-page rate is less than a minute or so. For example executing a viewtopic.php requires loading and compiling 650Kb of PHP source from 26 separate files, as well 19 data files from the cache directory. The main latency isn’t actually from compiling the 650Kb of source, it’s actually reading all those HDD seeks need to read those 50 plus inodes and 200 odd data blocks at a worst case. Now the read for each file might be atomic but each file open as well as each read could cause a process reschedule / context switch before the next I/Os can be scheduled. If the shared service is on a busy server with a lot of active contention this could take 10s of seconds.
- The situation for the MySQL access is similar in that the MySQL servers on such systems also have a high contention ratio and might be serving 1,000s or even perhaps up to 10,000 tables across hundred 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 256Kb LAMP, as this is sufficient to install Xcache or APC.
- With a standard phpBB application, even an 8Mb code cache is sufficient to get a 99.5% hit rate on PHP code. 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 an HVS with PHP code and data caching enabled will effectively remove all physical I/Os which cause process rescheduling. The main delay now become solely the execution of that 20K lines or so of code needed to render the webpage.
- 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 256Mb 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 HVS will typically be a order of magnitude less than a SWS. Adding 256Mb would allow optimisation of the MySQL database and effective 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 now be considered.
This being said a shared web service is an entirely realistic 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 the usage volumes rise much above this then a move to a hosted virtual service should be considered. Very few boards will need a dedicated server, and the main reason for this relates to I/O queuing issue.