There are numerous articles floating around in internet land eschewing the various ways to squeeze the very last drop of performance from PHP. Unfortunately most of the time these articles list micro-optimisations that are quite frankly a complete waste of time. Two of the all-time classics have to be “echo is faster than print” and the whole “single vs double quoted strings”.

What most of the articles seem to ignore, or at least gloss over, is that PHP rarely stands on it’s own. More often than not it’s a single component of a larger (typically LAMP based) application.

There’s no point changing all instances of print to echo or worrying about which quoting style to use, while ignoring the mammoth database query that runs on every page request against fifteen unindexed tables containing millions of records.

The best way to ensure good application performance is to write Good Code™ and implement Good Database Design™ in the first place. Both of which are topics I’ll be covering in the future. In the mean time, here’s my guide to practical optimisations for LAMP applications…

• Use an opcode cache such as APC or XCache.
  This is mostly likely the single biggest performance gain you will achieve with PHP!
• Use E_STRICT and don’t suppress errors.
  Setting error_reporting to E_STRICT and not using @ to suppress errors and warnings will catch most common code bugs such as undefined variables and unquoted strings. Use the following to ignore errors when absolutely necessary:
  $old = error_reporting(0);
action();
error_reporting($old);
• Identify slow queries.
  Turn on the Slow Query Log in MySQL and use EXPLAIN to examine offending queries.
• Make Fewer HTTP Requests.
  Combine and minify your Javascript and CSS files. Consider implementing CSS sprites to reduce requests for images.
• Enable output compression on the webserver.
  This will reduce the amount of data travelling over the network, reducing the time required to load each page.
• Use the Expires header.
  This will greatly reduce the number of requests for static content such as images, Javascript and CSS.

The above tips should be at the top of your optimisation list as they are almost certainly the ones that will provide the largest performance increases. Once they have been taken care of we move into the realms of more specific optimisations of code, queries and server settings; which I’ll be covering in future posts.

As a programmer, I’ve often needed to generate random data of one kind or another, whether it be names, addresses or just random text. Such a task is usually very boring and tedious, and I’ve thought on several occassions ‘I should really write a tool to automate this’. Well now I have…

Introducing SPF_Random

SPF_Random is the latest class to join Si’s PHP Framework (SPF) and includes methods to generate various forms of random data:

• names (forenames, surnames and full names)
• addresses
• postcodes
• phone numbers
• dates
• job titles
• lorem ipsum text (words or paragraphs)

It’s not perfect (addresses and phone numbers are UK oriented for example) and I’m sure there are better solutions elsewhere on the interweb; but it’s certainly a very quick and simple way to generate personal details for a hundred random people. Plus it’s a completely stand-alone class, you don’t need to download the whole framework to be able to use it.

For the future I’m thinking of adding IP addresses, alphanumeric strings and item lists (especially useful for <select> lists).

• Download SPF_Random

PHP 5 included a new error reporting directive, E_STRICT, which according to the manual allows PHP to “suggest changes to your code which will ensure the best interoperability and forward compatibility“.

Basically it catches things that have been deprecated (such as call-time pass-by-reference) or are technically incorrect (such as calling a static method in a non-static way, and vice-versa).

I have this enabled on my development and production servers. Mainly because I want to know when I do something stupid like call a static method incorrectly, but also because I’m a PHP purist and believe the PHP error log shouldn’t contain anything unless explicitly put there by the application.

Recently I’ve noticed that numerous PHP applications and libraries emit all kinds of E_STRICT notices. Offenders noted so far are ADOdb, Smarty, WordPress, Plogger and Gallery v2.

All of these are fanastic projects but the fact the code within them emits E_STRICT notices means they’re harder for me to implement and use. I usually end up having to globally search replace something, or call error-reporting() to set a lower error reporting level. The latter is made a lot harder when the application has multiple entry points (e.g. WordPress and Plogger).

The reasons behind these E_STRICT notices are usually due to the project remaining backwardly compatible with PHP4. Especially with regard to call-time pass-by-reference, as this was used extensively in PHP4 to speed up code execution when passing objects around. However the incorrect calling of a static method is a different story, it’s just sloppy OOP in my opinion. Simply testing with E_STRICT turned on would highlight these and fixing them would save a lot of headaches for those of us who run servers with E_STRICT turned on.

Alas, for that to happen we’d need projects to forego the backward compatibility with PHP4, and that is extremely unlikely. No large project with any sense is going to tear their community in two because of people like me harping on about E_STRICT.

Our only hope is for new projects to spring up focused solely on PHP5 and “proper” OOP…