I am raising these issues (i) from a basis of some expertise and (ii) because I have implemented and benchmarked most of the points (that I discuss here in a series of detailed articles).
Key to these discussions is an observation that the phpBB installed community falls largely into two camps: large-scale forums running on dedicated servers or VMs and where the admin has root access; and the large bulk of forums (perhaps 95% by number) which run on a low-cost ISP shared-service templates. In the former case, such site admins usually tune up the system to use mod_php or FastCGI and PHP opcode caches such as APC or Xcache, etc.. In the latter “95%” case, the forum installers have none of these freedoms and have to take the Apache/IIS service as offered by their hosting supplier, have limited tuning through .htaccess files, etc.
The current phpBB implementation has some features that lead to unnecessarily poor performance in this second case that could easily be addressed within an evolving phpBB architecture, baring in mind the key characteristics of this type of service:
- The PHP RTS is activated per HTTP request in the account’s UID.
- No code caching is available, so the entire included module set needs reading in and compiling per request.
- These systems are nearly always physical disk I/O bound, so any read requests which are not already in the file-system cache tend to kill performance. The rough ratios are in the time that it takes to read in one file from disk, the system can compile ~10-20K lines of source code or execute ~500K lines of PHP code.
- Basic webserver tuning though the .htaccess file to ensure that all compression and local caching possible occurs. OK this isn’t coding issue, but we don’t even have a 101 article on this in the kBase.
- The current file cache uses a one file-per-object policy and this performs terribly on shared service hosts. (It also performs terribly on larger systems as well, but at least memory based alternatives exist for these.) I’ve developed globfile cache which uses a simple single compressed data file. This can improve request response times by up to 30% on this type of system. (This is also 3.0.x compliant.)
- Code globbing – that is dynamically compiling a set main-path includes into a single composite file – can generate similar response savings, and again I have a 3.0.8 demonstrator of this working.
- The retention of support for PHP 4.3 constrains the implementation to the PHP 4 object model. Who will run PHP 4 for phpBB 3.1 let alone 3.2? This should be dropped and a proper PHP 5 standard be implemented.
- the modulariation / include strategy is sloppy and this needs to be overhauled by a coherent and standard approach to encapsulation. This work should be done for 3.2.
- the template engine implementation is a mess and really needs rewriting.
- the session.php is “hot” yet it has debris and convolved coding in it. This is due for a thorough review.