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: http://www.php.net/manual/migration55.new-features.php.
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 all_php_builds.zip - 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 3.0.2.2 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.
Notes
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
Thanks. So, just to clear up any confusion, is there now absolutely NO reason to use Wincache under IIS 7+?
ReplyDeleteFrom 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+?
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.
DeleteI 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.
Hi Rob,
DeleteFirst 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,
Hi Stépahane,
DeleteI'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.