eZ Publish: Performance Best Practices

Testing should not be postponed until just before the project goes live. Instead, it should be an ongoing effort that validates each step of development and implementation. This section describes some testing techniques that will help you analyze and optimize performance.

Using the debug output

The debug output provided by eZ Publish is extremely useful. It is enabled in the site.ini configuration file ([DebugSettings], DebugOutput=enabled). Debug output generates verbose notices, warnings and errors, and also provides a profiling tool that shows how page generation time is divided among the page construction phases. While the profiler was not specifically designed as a performance or load testing tool, it will give you the ability to immediately identify bottlenecks and major issues during unit testing and thus to correct many potential problems.

For example, after enabling caching, you can use the profiler to ensure that SQL queries are not executed when cache blocks are enabled. You should see three SQL queries on a standard page load when ViewCaching is enabled. If you see more, for instance 20 or 30, something is wrong.

It's quite common to ignore non-critical messages in the debug output (such as compiler errors, uninitialized variables, etc). However, even if the errors have (or seem to have) no impact, they should be fixed as soon as possible. Errors are indicators of system instability or misconfiguration, and may have side effects, including performance impacts. For the sake of project maintenance, the debug output should show a clean system.

Error log

Another useful source of information is the error log in var/log/error.log. It can, among other things, show you when a file that doesn't exist is being requested by a browser (for example a JavaScript file you have removed but forgot to remove from the template code or the website icon). When this happens, a request is sent to eZ Publish with a "module not found" error, and every page load actually starts two instances of eZ Publish, which uses a lot of unnecessary server resources.

Load testing

Load testing must be run periodically during project development and implementation. To start load tests just before launching a project is extremely risky and unprofessional. Unfortunately, this is a common mistake because developers, testers and project managers usually focus on visible tasks (such as page layout, features, etc) and not on transparent infrastructure issues (such as performance).

Several tools can help you in the load testing process, such as Apache Benchmark (provided with the Apache HTTP server), Siege or Jmeter. They show you how well your project scales as the number of visitors increases. However, be aware that these tools can severely impact your server if not used properly, since they can start hundreds of simultaneous requests to your website.

There are two aspects to benchmarking project performance. The first is benchmarking from within the local network or from the server itself. These benchmarks show HTTP server response time without any bandwidth variables. Second, benchmarking your platform's network availability in a "live" environment, where bandwidth varies, provides a view of your system's performance from your users' perspective.