For all the Windows-bound PHP users out there, consider yourselves warned: even if you’re running the (supposedly) thread-safe PHP Win32 binary redistribution, you’re still susceptible to PHP Access Violation Errors, race problems, heap corruption, and much worse if you use the popular eAccelerator opcode-caching extension.
We did our testing with the binaries compiled by SiteBuddy using the latest versions of both PHP and eAccelerator. Almost immediately after initiating a stress test on our test servers we experienced the dreaded “PHP Access Violation” error – which brings down the entire IIS Worker Process to its heels.
This bug is only encountered on Windows on both Apache and IIS when PHP is installed as *SAPI module. If you’re using it as a CGI process (not recommended!) or via a FastCGI handler (like this excellent one by Microsoft), you’re not affected by this “bug.”1
Ever since PHP released their “guaranteed thread-safe” package for download a month or two ago, it’s been a much more… relaxing world for Windows sysadmins everywhere. But it’s not really such a bright idea to run even a lightly-loaded server w/ PHP without an opcode-caching extension installed.
If you’re in the market for another opcode cacher, we recommend XCache; produced by the guys behind the mighty-quick lighttpd. It too is free, except it’s also thread-safe and has some nice bonus features thrown in the mix. Turk MMCache is history, and APC has (more than) its share of compatibility issues with various popular open source projects. As of the time of this post, we haven’t encountered any issues with XCache and it seems to be the right choice.
Placed in quotation marks seeing as many fans of PHP, eAccelerator, and a good many more will insist that this is “expected behavior” and isn’t really a bug; being an inherit “feature” of CGI-based processes. ↩
xcache is pretty much the ONLY choice.
It turns out PHP itself is also not thread-safe (even though they pretend it is):
http://neosmart.net/blog/2008/dont-believe-the-lies-php-isnt-thread-safe-yet/
@Mahmoud Al-Qudsi
I do a lot of core customization as well as sapi development in PHP (the interpreter, not scripting.) I can respect that you are a knowledgeable coder from the projects that you have done, but you seem to know little about PHP internals. You should look more deeply into the subject more before writing more posts about the ‘lies’ and ‘pretending’ associated with PHP threading.
There is usually five parts to a PHP solution. A server, a server to PHP interface, the PHP library, PHP extension interfaces, and extension libraries. Each of these parts are often developed by different groups/individuals and they often don’t play well with each other. If even one of them is not threadsafe it will break the whole system. The PHP lib is threadsafe, and most servers are as well, but many SAPIs are not, and many extensions are not.
From what I have seen and *experienced*, the only threadsafe SAPI that ships with PHP is the Fastcgi SAPI. All others will break if they are threaded.
If the SAPI and PHP threads successfully, extension interfaces and/or extension libraries can still break the parent process if they are not thread safe.