Friday 6 June 2014

PHP 5.5 Builds

PHP 5.5

A little bit late but I've updated to PHP 5.5.  There are a few improvements that I like, and a great opcache extension, all covered in detail here so no need to go on about it:

New PHP extension builds

New builds of php_sqlsrv and php_spidermonkey are available including PHP 5.5 supporting 32 and 64 bits (64-bit builds are in the x64 folder of the zip file).

Download - new builds of various 3rd party extensions, updated 19 June 2014:

  • Microsoft SQL Server Driver for PHP 5.3, 5.4 and 5.5 (php_sqlsrv and php_pdo_sqlsrv).  64 bit drivers are in the x64 folder of the zip file.  This is version built 19 June 2014, a quick rebuild to fix a bug I missed a few days ago, reported by Marius Serban - many thanks Marius.
  • php_spidermonkey for PHP 5.3, 5.4 and 5.5.  This extension needs updating to work with Mozilla's newest version of Spidermonkey.  PHP 5.5 64-bit build is included in the x64 folder of the zip file.


I have rebuilt all the extensions I use on Windows and put them all in one big zip file.  Some notes on sqlsrv are below.  I have not tested all versions, just rebuilt.  There is a 64-bit build of Spidermonkey in the x64 folder of the zip file as of 19 June 2014. Everything is built on either the VC9 (PHP 5.3, 5.4) or VC11 (PHP 5.5) compiler.

Sqlsrv changes

Update 30 Aug 2014: sqlsrv for PHP 5.6 is included on this page: Unofficial Microsoft SQL Server Driver for PHP

The sqlsrv driver has a fix to a bug found by Charles Durrant ( which I too recently experienced when running PHP-32 on a 64 bit server.  I noted Charles's post when he first reported the bug, but tried my best to avoid working on the source code until I had to... Charles saved me a huge amount of time, so thank you to him.  My fix is different, I have repaired all of Microsoft's dodgy auto pointers and completely rewritten the horrible function that caused the crash.  If anyone uses these new builds and spots memory leaks or bugs due to these changes, please let me know and I'll fix them within a day or two.

Other stuff

Netbeans - very cool

Some time ago I switched from Eclipse to Netbeans for PHP development because Eclipse was having trouble handling very large source files (such as TCPDF) and it was a little bit generic.  I have never looked back, Netbeans just gets better and better and is a joy to work with -  It is free and a perfect platform for PHP development, with support for PHP, HTML, CSS and Javascript.

Stop using Wincache

Wincache does not speed up PHP on IIS 7+, and causes it to seize up at random times.  If you need an op-code cache use the distributed one with PHP 5.5, or just make do.  IIS 7.5 and later are so quick and reliable, wincache is not going to make a significant difference and might actually slow things down.  Which leads to...

IIS 7.5 and later - very cool

I've been extremely impressed by IIS over the past few years.  Ever since 7.5 it's been a real monster of a web server, incredibly fast and easy to look after and set up.  Well done Microsoft - and this is a very fine web site too:  It has plenty of support for running PHP on IIS.


  1. Thanks. So, just to clear up any confusion, is there now absolutely NO reason to use Wincache under IIS 7+?

    From what I understand (and I'm quite confused!) Wincache has several types of 'caches'. Have these all been replaced by something else, meaning that Wincache no longer offers any value under IIS 7+?

    1. Thanks Andy, great question. I recommend not to use it based on my experience. It might seem glib to sum it up in a sentence or two, so I'll try to elaborate.

      I was running a busy site on IIS 7.5 with php 5.4 and Wincache. It locked every 3 days, or more accurately ground to a halt with pile-ups of php processes popping up in task manager, eventually bringing the whole server down. I analysed and tried switching off wincache. It not only stopped the problem, the web site visibly came alive - without any speed measurements needed, it was serving up pages like never before. Very fast. That's when my eyes were opened to how good IIS had become.

      There is a scenario where wincache will still be needed: by developers that use its manual caching functions. To stop using it would require writing replacement caching code, possibly using php's built in shmop extension.

      Another type of caching wincache does is web sessions. It makes session handling very fast... but there is a down side: when IIS recycles or restarts, the sessions are all wiped out or become incomplete. When I tried it, I could not once guarantee a consistent session state - users kept complaining that data was disappearing. My life got much better when I wrote my own session handlers using the php session api, or reverted to session files.

      Finally, wincache can cache static files that might be loaded with file_get_contents or some other api. For me, it's not enough reason to use it, the benefit is small. If this feature makes a big difference to a site I would guess that the php code could be optimised.

      To summarise why I don't recommend Wincache:
      * PHP 5.5 has its own op cache.
      * IIS caches static files and more.
      * Stability and integrity.

    2. Hi Rob,

      First of all, thank your for all you work.

      I was wondering one thing about your point on Wincache: do you advice to not use it for all its capacities or only for its OpCode cache?

      I'm in particular thinking about the user cache and file content / file resolve path caches?

      Many thanks,

    3. Hi Stépahane,

      I'll start by saying this is hypothetical, I didn't use either of those features. Furthermore, Wincache has been upgraded since I last used it.

      In my tests I found that there was a sharing issue between multiple IIS worker processes, and when one worker process restarted it occasionally spoilt/blocked the cache for the others. (My web site contained things like overlapping 'include' directories, but everything was within the rules of PHP.)

      The user cache might or might not be affected, you would need to devise an extensive test. If it works for you then there's no reason not to use it.

      The file cache would probably work without a problem, because if a file was lost from the cache it would be re-cached automatically.

      There is only one other consideration and should only be considered if your server is so busy it's running out of memory or running too slowly - for every extension you add to php.ini, the footprint (memory requirement) of PHP is larger and PHP will have all the functions, classes, constants from the extension added to its namespace. By removing extensions you don't need, you might be able to add a little bit of extra capacity to your server.


Note: only a member of this blog may post a comment.