Extending the scope of the phpBB cache

[Kellanved]

There are numerous comparisons of include_once vs include and I am not familiar with the drupal one. The general trend is that the plain include (i.e. without once) is faster, with later php versions having equal performance for both. There are a few stating that 'include_once' is faster, but from the implementation - it requires a system stat call - I don't see how that could be. Anyhow, opcode caches like APC can replace all include types with superior versions.

For future releases using a consistent way for loading modules is an absolute must.

AcydBurn: no, the query used rounded time to avoid that.

[TerryE]

Nils, We don't want to falling into the same trap as the benchmarkers. Improving modularisation and autoload could enhance performance for the top 5% or so of installs -- the high volume boards running on dedicated/virtual host services, but it might do this whilst making things worse for the other 95% of phpBB boards -- those running on shared services (and whose sysadmins flood the phpBB support forum because they can't get to grips with the phpBB source code).

So whilst, I agree that some form of autoload approach is needed, I also feel that we need an abstraction model -- much in the way that we've done for the DBAL and ACM -- to handle module management with a unified inclusion API that can either use cached aggregation or not on a system config selection. The way this might look at an API level (in the case of Viewtopic -- instead of the current include preamble:

Code: Select all

include($phpbb_root_path . 'common.' . $phpEx);
include($phpbb_root_path . 'includes/functions_display.' . $phpEx);
include($phpbb_root_path . 'includes/bbcode.' . $phpEx);
...
// Load custom profile fields
if ($config['load_cpf_viewtopic'])
{
    if (!class_exists('custom_profile'))
    {
        include($phpbb_root_path . 'includes/functions_profile_fields.' . $phpEx);
    }
...  

we would have something like

Code: Select all

$commonMod = file_exists($phpbb_root_path . 'cache/tpl_common.' . $phpEx) ? 'cache/tpl_common.' : 'common.';
include($phpbb_root_path . $commonMod . $phpEx);
cache_module('viewtopic', 
             array ( true => array ( 'display_forums' => 'includes/functions_display', 
                                     'class bbcode' => 'includes/bbcode' ),
                    'load_cpf_viewtopic' => array('class custom_profile' => 'includes/functions_profile_fields') )
            );  

This sort of data driven approach allows an encapsulated implementation of module loading. Now whether we use include or include_once, etc. is matter of implementation hidden from the rest of the phhBB application. We could consider alternate implementation strategie, for example:

• A simple module load.
• It could set up the control structures autoloading and define an __autoload() function which uses them to do JiT loading.
• Reprocess the loaded modules to create a compact cached module which aggregates all of the modules in (in this case) the viewtopic group, so that subsequent loads use the processed composite which has string literal load paths in its includes.

These variants are abstracted from the source definition. Collecting the loads into this sort of unified structure also means that we can add debug instrumentation to monitor load performance if we so wish.

Anyway that's my musings

[Acyd Burn]

AcydBurn: no, the query used rounded time to avoid that.

I know, but there were still hundreds of cache files. We (Chris and i) analysed the usage at phpbb.com and then decided to drop it based on these results.

[TerryE]

I know, but there were still hundreds of cache files. We (Chris and i) analysed the usage at phpbb.com and then decided to drop it based on these results.

If we think in terms of shared service = acm_files + low transaction rates versus virtual/dedicated service = acm_memory + high transaction rates, we shouldn't be doing this for an acm_files based cache anyway. As I said oringinally: "this would give a modest but worthwhile performance boost to (2) [virtual/dedicated services]". The way to fix this is for the acm implementation to define a minimum TTL threshold below which TTL would be treated as 0. This would be 300 for acm_files, say, but would be 60 for acm_memory. Hence this strategy wouldn't apply to acm_files implementations.