HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.
Proud to be a PHP Open Source CMS
Learn more

ocPortal Tutorial: Optimising

Written by Chris Graham, ocProducts
ocPortal is very heavily optimised so that pages load as quickly as possible. This tutorial will provide information on techniques and issues for increasing throughput, so that your site may support more visitors.


Table of contents

  1. ocPortal Tutorial: Optimising
    1. Making PHP run faster
    2. ocPortal cacheing
    3. Persistant cache
    4. Server
    5. Server farms
    6. See also

Making PHP run faster

Speed can be approximately doubled if an "opcode cache" is installed as a PHP extension. These caches cache compiled PHP code so that PHP does not need to re-compile scripts on every page view. The 3 main solutions for this are:
  • Zend Optimizer (part of it is free but mostly it is commercial; made by the company behind PHP)
  • eAccelerator (free, carried on from Turck mmcache)
  • ionCube PHP Accelerator (free)
  • APC (free)

We recommend using eAccelerator, for reasons that will become apparent.
Only one opcode cache can be used, and they often need to be manually compiled against the PHP version on the server and then installed as an extension. Such system administation is beyond the scope of this tutorial.

ocPortal cacheing

ocPortal provides many forms of cache, to allow the system to run as quickly as is possible.
During development (when editing template files using external editors, or editing PHP code) we recommend that these are disabled so as to remove the necessity of emptying them a lot.

The ocPortal caches are:
  • language cache: this removes the need for ocPortal to parse the .ini language files on each load
  • template cache: this removes the need for ocPortal to parse the .tpl template files on each load
  • Comcode page cache: this removes the need for ocPortal to parse the .txt Comcode pages on each load
  • Comcode cache: this removes the need for ocPortal to parse Comcode whenever it is used
  • block cache: this removes the need for many blocks to be fully executed whenever they are viewed - they are cached against the parameters they are called up with using a per-block tailored scheme
  • theme image cache: this removes the need for ocPortal to search for theme image files whenever they are referenced by code (a code could translate to perhaps 10 different URLs, due to the flexibility of the system)
  • values caches: this isn't a specific cache, but cacheing of values such as member post counts removes the need for ocPortal to recalculate them on-the-fly
  • persistant cache: this is a very special cache that is explained in the next section

Server

A faster and more dedicated server will make ocPortal run faster. This may seem obvious, but in the efforts of optimisation, is easily forgotten.

CPU speed will be the most limiting factor for most websites: so this is the first thing that should be considered.

Server farms

ocPortal has special (but unofficial) support for running on server farms:
  • ocPortal file changes are architectured so that any changes call up a synchronisation hook which can be used to distribute filesystem changes across servers. As ocPortal requires no usage of FTP once installed, it presents the ideal managed solution for automated mirroring, once the initial network and synchronisation hook are created.
  • the ocPortal database system supports replication.

In order to implement file change synchronisation, you need to create a simple PHP file in data_custom/sync_script.php that defines these functions:

Code

/**
 * Provides a hook for file synchronisation between mirrored servers. Called after any file creation, deletion or edit.
 *
 * @param  PATH             File/directory name to sync on (may be full or relative path)
 */
function master__sync_file($filename)
{
   // Implementation details up to the network administrators; might work via NFS, FTP, etc
}

/**
 * Provides a hook for file-move synchronisation between mirrored servers. Called after any rename or move action.
 *
 * @param  PATH             File/directory name to move from (may be full or relative path)
 * @param  PATH             File/directory name to move to (may be full or relative path)
 */
function master__sync_file_move($old,$new)
{
   // Implementation details up to the network administrators; might work via NFS, FTP, etc
}

In order to implement replication, just change the 'db_site_host' and 'db_forums_host' values using config_editor.php (or editing info.php by hand in a text editor) so that they contain a comma-separated list of host names. The first host in the list must be the master server. It is assumed that each server has equivalent credentials and database naming. Due to the master server being a bottleneck, it will never be picked as a read-access server in the ranomisation process, unless there is only one slave.

Round-Robin DNS could be used to choose a frontend server from the farm randomly, or some other form of load balancing such as one based on a non-cacheing proxy server.

See also