Improve PHP application performance using opcode cacher and optimizer

One of university underpowered server cought "hiccup problems" during students rush at local Learning Management System (leading PHP LMS platform) during the end of semester. Because there was no chance for quick hardware upgrade I've checked server tuning check list again. Many basic settings was optimized (caches, all additional modules turned off etc.), but there was still room for small improvements. The big problem was memory limit under high load.

I've installed XCache PHP opcode cacher (they say it's production ready), and set it to cache most of common used code in RAM. Results was better than I suspected, maybe because of that application is utilizing a lot of PHP code. Under heavy load memory usage dropped about 3 times, the same gain factor was for CPU usage. I've checked if everything works ok and left it working with XCache then.

The next bottlenecks were database and CPU usage for some operations. It's hard to get further performance improvements of that scale without tweaking application code.

Polishing PHP application - Role of tests

Real life scenario:
Slightly changed requirements from category "eventually" - gives as result quite lot code changes.
An extra problem was that in one production environment it have to work on PHP 4, so application needs downgrading from PHP 5 mainly in XML processing area.

Solution:
Writing more tests for new features.
Gradually code fixing and refactoring.
As a result I have more clean, better working code with new features and potentially new undetected bugs :) .

Savings from using unit and regression testing are almost priceless.

Trying to do some changes like that in PHP production code without automated tests will be really painfull.

Mature programming languages and internationalization

Have you ever tried to implement application using character encoding other than Latin 1? What is deal with that? If you are using modern development platforms like Java or .Net - it just works. Let's omit other problems caused by bad implementation of internationalization issues in framework/library. Multilingual application scenario is simple - use internal UTF character encoding, allow transcoding from external systems at the API level (I/O operations with text files, databases etc.) - and your application will be able to write messages in most standardized character sets including Russian and Chinese.

What about other popular programming languages? Take for example Python 2.5 - recent version that could be used in production environment. It supports UTF strings processing, and character transcoding- but be aware - there are glitches and unimplemented UTF features, causing bad UTF processing. To get it work you have to use (sometimes ugly) workarounds. Here is nice presentation about these issues. There is hope that developers from open source community will fix that till let's say version 3.0.
Ruby is in better situation- as a younger language it has more properly adressed internationalization issues at the design stage. I suspect there is still more work to do.

What about old work horse of web applications development- PHP in newest stable version 5.5.2. It came a long road, but still have problems caused by legacy of non integrated separated libraries. It has long list of options to set encoding like internal encoding, http input output encoding, and many more affecting single libraries.

So what about using mbstring module (multibyte string representation) , setting UTF as internal encoding and sticking to it. Situation is worse than in Python- many even simple string functions can't process multibyte strings in proper way. The Solution is to write own workarounds or use third party libraries like PHP utf8. Here is good list of PHP internationalization issues. Last week I have checked xml import support for old PHP application- it caused problems with Latin2 encoding. The reason was simple: The XML SAX parser supports only ISO-8859-1, UTF-8 and US-ASCII encodings.

Such low detail problems could potentially take a lot of precious project time. So if your next application will use character set other than Latin 1, you should consider good internationalization support by chosen development and production platform.