RSS Feeds

Use cases for phpBB

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. 

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

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.