Very exciting to see the PHP team set the date for the PHP 7.0 final (gold) release.
Thursday November 12th – 90 days from today, mark your calendars!
It will be as if millions of servers cried out as their loads were cut in half.
The first PHP 7.0 release candidate will ship August 20th, 2015 (this coming Thursday!)
All changes to PHP 7.0 now are stabilization/fixes only (feature frozen).
In 30 days, on September 14th 2015, the PHP team will start the PHP 7.1 master trunk branch as PHP 5.4 is marked “end of life”
If you need legacy code support, be sure to read my post on how to put mysql functions back into PHP 7.0
PHP 7 will go “release candidate” on August 20th 2015 which is very exciting because it will instantly be twice as fast as PHP 5.6 (and all previous versions). PHP7 gives HHVM a run for the money and takes 5 minutes to compile instead of hours for HHVM.
But there is a catch – if you have any legacy code that uses the mysql_* functions, they will stop working entirely in PHP 7. Not just a warning, not just deprecated, but gone, fatal.
However, it is easy to get them back without using a wrapper or modifying your code…
So you finally got HHVM 3.2 installed and running
and instinctively go to your phpinfo page to check it out…
but there nothing there, only “HipHop” …disappointing isn’t it?
So I whipped this up real quick as a phpinfo replacement:
While everyone has been distracted admiring PHP-NG, a great PHP project has quietly come back from the dead – Suhosin !
Suhosin is a well regarded security extension for PHP by Stefan Esser that had stopped getting updates after PHP 5.3. Perhaps it was due to more dramatic internal changes to the PHP core with 5.4 making it difficult to keep up. Linux distributions such as Debian that added Suhosin seeing its value, dropped it after updates stopped. Suhosin only worked up to PHP 5.3 – until now.
Suhosin can do neat tricks like disable EVAL and the regex /e modifier in PHP which the core of PHP cannot do by itself (or more accurately the core developers refuse to address). Suhosin also has many other options to help make PHP safer to use in a shared environment or where a server might be running a great deal of third-party code (ie. WordPress/plugins).
2015 UPDATE: new wiki page for HHVM on CentOS7 with alternate instructions
While building HHVM (HipHop Virtual Machine) for faster PHP on CentOS 6.x was pretty much a nightmare because almost none of third-party libraries are available from major repositories, the freshly released CentOS 7.0 solves most of this problem as it has far newer packages available from EPEL (because it has roots in more modern Fedora 19).
Note that unlike PHP/PHPNG, HHVM requires major resources to build. You may be used to making PHP in 15 minutes on a little old 256mb 1ghz box. You can forget that with HHVM which is a beast to compile. 1gb ram minimum and lots of cpu power required to keep it an hour or two (this is part of why PHP NG instead is so exciting because it will be so much easier to custom build).
Zeev Suraski (CTO of Zend and therefore an extremely qualified authority on PHP NG) has written a fascinating article comparing the performance of PHPNG against the current HHVM versions. A must read.
Perhaps even more importantly, he has written about the current state and future of PHP NG.
correction: php core developers have urged that it is improper to call this version “5.7” (despite the versioning file stating so)
PHP 5.7 PHP NG is still in alpha development, however it is starting to show breathtaking performance improvements over 5.6 while maintaining virtually complete compatibility.
Dmitry Stogov has been hard at work since his first announcement in mid-January 2014 and milestone update in early-May to keep folding in more and more ideas to increase PHP speed (with significant contributions by Xinchen Hui, Nikita Popov and others).
Six months later in mid-July, their efforts are really bearing fruit and PHP
5.7 NG is about to become nearly 100% faster than PHP 5.6 when rendering the front page of a stock WordPress 3.6 installation:
PHP 5.6, 1000 renderings of WP front page = 26.756 seconds
PHP NG, 1000 renderings of WP front page = 14.810 seconds
update: now with PHP 5.7 (PHPng) comparison
Was really curious to follow up on PHP 5.6 with “real world” benchmarks so I built up a machine today for some quick’n’dirty tests. (I’ll add more tests to this at a later date as I have actual things to do this weekend and this was quite a bit of work).
Everything was allowed to pre-cache heavily, linux, mysql, php opcache, etc. this is just a raw php performance test (but no wp-cache, all dynamic pages)
Two tests: (for now)
1) directly calling the wordpress front page via php-fpm via the fcgi utility, which bypasses all of the web front end (nginx) so it is pure PHP speed
1000 passes (one pass at a time, single file asap via fcgi)
PHP 5.4 median = 28.562 seconds
PHP 5.6 median = 26.783 seconds
PHP 5.7 median = 19.405 seconds
6.22% improvement with PHP 5.6
32.06% improvement with PHP 5.7
2) full web interface benchmark with logged in admin user, going into view “all posts” in the wp-admin backend (/wp-admin/edit.php) – this makes WordPress work really hard because it is loading all of the engine, plus the wp-admin code, plus authorizing the user via the cookie
1000 passes (one pass at a time, single file asap via curl)
PHP 5.4 median = 42.523
PHP 5.6 median = 39.455
PHP 5.7 median = 29.498
7.21% improvement with PHP 5.6
30.63% improvement with PHP 5.7
Intel Quad Core i5 @ 3ghz
CentOS 6.5 64bit, MariaDB 10.0.11, Nginx 1.6.0, PHP 5.4.30/5.6.0beta4, Zend Opcache 7.0.4
WordPress 3.9.1 (stock with wp-cron disabled)
All built with GCC 4.8.2 and I made PHP 5.4 and 5.6 both use the same new Zend Opcache (because it is amazing)
I’ll do more comparisons and maybe even build PHP 5.5 at a later date.
Let me know if there are any specific requests for good things to compare.
Added PHP 5.7 (aka PHPNG) something to look foward to in 2015
There is still another week of voting left before it becomes official on March 7th but the results are pretty much complete. PHP 5.5 will definitely integrate Zend Optimizer Plus opcache, built right into the distribution.
This is a good thing for the future of PHP but will require some changes for webhosts.
Since even PHP 5.4 is not widely adopted yet, we are talking 2015 for the masses.
But you don’t have to wait for PHP 5.5, you can replace APC, Xcache and eAccelerator immediately with Zend Optimizer Plus via the newly opensourced code and I’ve made a free control panel for it. Works fine on PHP 5.3 and 5.4 and you’ll typically see a minimum 10% performance boost on busy websites over those other opcode caches because of it’s extra optimization passes.
Feb 13 update! Zend Optimizer+ is now officially open source so these instructions to manually install the binary are no longer needed! Go here instead: https://github.com/zend-dev/ZendOptimizerPlus/
I’ve also written a control panel for it which you can find here:
With Zend supposedly open-sourcing their Optimizer+ opcode cache for PHP, likely replacing APC, I want to preview what I might be dealing with and any limitations/advantages.
However I did not want to install a bunch of unknown zend stuff into php slowing it down or causing conflicts, I only wanted the bare minimum and know exactly what I am installing.
Turns out it’s rather easy once you know what to look for.
As PHP internals explores replacing the APC opcode cache with an open-sourced Zend Optimizer Plus an interesting benchmark was published. It shows WordPress serving nearly 10% more pages per second than APC while using Optimizer+ (both under PHP 5.5).
Following a series of memory leaks and other problems, the 3.1.14 beta release of the APC opcode cache for PHP has been recalled and removed from the pecl site by Rasmus as it’s not currently suitable for use.
I noticed the memory problem a week or two ago. I’ve carefully tested each revision in the trunk after the 3.1.13 release and have found revision 328264 to be the last good update if you want some of the subtle bug fixes since 3.1.13 without the later problems.
You can fetch a specific revision via svn like so:
svn co -r 328264 http://svn.php.net/repository/pecl/apc/trunk/
This was the changelog for 3.1.14 which has been since removed: (more…)
There has been a growing discussion about this in PHP internals but now there is a semi-official wiki page explaining what is going to happen with the replacement of APC by Zend open-sourcing their OptimizerPlus opcode cache.
Right now it’s only a “proposal” but if you look at the internals discussion, it’s almost certainly going to happen, it’s just a matter of “when” not “if”.
Given that the few people working on APC would mostly likely stop and focus instead on Optimizer+, APC is now in theory, doomed. Which is a bit crazy considering how much code is out there to take advantage of it’s user cache (which is significantly faster than say memcached on a local single server). OptimizerPlus has no user-cache shared memory support at all, it’s only an opcode cache.
Not sure why the benchmark uses “ancient” WordPress 2.1.1 but in theory this would give even the newest WordPress 3.5 a five to ten percent performance boost.
PHP 5.5.0 will reach a feature freeze is on February 7th, 2013, just two weeks away, for it’s first beta release.
There was some discussion of including the APC opcode cache into 5.5 but this will decidedly NOT happen because it would delay release by several months.
However in an interesting twist, there is now discussion of open-sourcing ZEND OPTIMIZER PLUS and including with PHP 5.5 instead.
Zend Optimizer+ is a commercial opcode cache for PHP and is slightly faster than APC but currently used on only a small percentage of servers compared to APC.
This essentially would doom APC, despite the suggestion it would remain available as there are only a few contributors to APC at this time and then would obviously switch to the zend optimizer+ sooner or later.
Remember, PHP 5.3 will reach end-of-life in March with the release of PHP 5.5.0
News of an exciting discovery about making Suhosin work with PHP 5.4 that I missed from last week!
Apparently Jan Ingvoldstad (aka jani) has found that by disabling the multibyte string protection in Suhosin allows it to run with PHP 5.4 and perhaps keep it’s other protections.
So a somewhat serious sacrifice to at least get the remaining protections for now.
It’s better than nothing and at least a start!
Jani points out the problem lies within Suhosin trying to reference internal functions in php 5.4 that no longer exist from php 5.3 – a rewrite of rfc1867.c will be needed to affect a proper fix, but that is a far more serious undertaking that might be a long way away.
I’ve tried to contact him to get his patched source copy. If I do not hear back I will attempt to do the same modifications to the source that he describes. Then it will require a great deal of testing.
This discovery is just in time as PHP 5.3 reaches end-of-life in March.
Update: He has posted his modifications! – I will compile and test this week…
PHP 5.3.21 was just released on January 17th but it was relatively minor with only a few fixes.
PHP 5.3.22 will be branched on January 30th and released on February 14th. It contains twice the fixes that look a bit more serious.
It should also be noted that PHP 5.2.23 in March 2013 will most likely be the FINAL release of PHP 5.3 as it goes into end-of-life with the release of PHP 5.5 This means that 5.3 will only receive security related bug fixes for one more year and then it’s over.
The really bad thing about this is that suhosin does not exist for the current PHP 5.4 and may likely never happen. To a lesser extent, magic-quotes no longer exists in PHP 5.4 and while it’s the subject of some mockery because of the mess it creates, it does make life a little harder for attackers.
On the plus side PHP 5.4 is measurably faster (10-20%) than PHP 5.3 and uses half the memory in many cases. The often-used silence operator (@) in PHP 5.3 has much better performance in PHP 5.4
The biggest problem most people will face changing from 5.3 to 5.4 is relatively trivial – you will receive many more warnings and deprecation notices but you can solve that for the short term by changing the error_log setting in php.ini to
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT
Just don’t ignore them forever because those things will certainly break under 5.5
- Zend Engine: . Fixed bug #63899 (Use after scope error in zend_compile). (Laruence) . Fixed bug #63762 (Sigsegv when Exception::$trace is changed by user). (Johannes) . Fixed bug #63462 (Magic methods called twice for unset protected properties). (Stas) - Core . Fixed bug #63943 (Bad warning text from strpos() on empty needle). (Laruence) - cURL extension: . Fixed bug (segfault due to libcurl connection caching). (Pierrick) . Fixed bug #63795 (CURL >= 7.28.0 no longer support value 1 for CURLOPT_SSL_VERIFYHOST). (Pierrick) . Fixed bug #63352 (Can't enable hostname validation when using curl stream wrappers). (Pierrick) . Fixed bug #55438 (Curlwapper is not sending http header randomly). (email@example.com, Pierrick) - Date: . Fixed bug #55397 (comparsion of incomplete DateTime causes SIGSEGV). (Laruence, Derick) - FPM: . Fixed bug #63999 (php with fpm fails to build on Solaris 10 or 11). (Adam)
PHP 5.4.9 final will be released on Thursday November 22nd, 2012
PHP 5.4 runs WordPress roughly 10% faster than PHP 5.3 and uses 30% less memory.
Here are the important bug fixes in PHP 5.4.9 (vs 5.4.8)
I recently tried PHP 5.4.8 on a production server and the memory-use decrease and performance increase was outstanding over PHP 5.2/5.3, truly impressive.
However despite the thrill, I had to roll back to PHP 5.3 after a couple days. Why? Not because of compatibility, there were only a couple of relatively easy to fix issues. Because it felt like we were running around naked without Suhosin which no longer works after PHP 5.3
Stefan Esser seems to have gone idle on updates for PHP 5.4, there was only an initial dev release several months ago (0.9.34-dev) and nothing since.
So I am calling on the “titans of industry” to make a donation to Stefan with a note encouraging him to continue the development for PHP 5.4 There seems to be a donation link here and I found another one here
If you aren’t running PHP 5.4 yet, you should be soon. Meanwhile those on PHP 5.3 who are not running the Suhosin extension should definitely install it. You can easily find php.ini tuning guides for suhosin around the web (specifically for WordPress too). It might save your server someday from being compromised by a 0-day.
I’ve recently had to abandon using eaccelerator because they are just not keeping up anymore with PHP releases and they even removed variable data cache support just to get PHP 5.3 compatibility. It’s sad because they were the fastest and most stable for years.
So I have been testing xcache and APC instead.
One trick I use on large/active servers for an additional performance boost is to turn off the file stat feature on the PHP opcode cache. This makes it stop checking the timestamp on each and every PHP file executed. WordPress for example has over 100 php files totaling nearly 3 megabytes on a typical install.
You’d use ONE of these directives in php.ini depending which opcode cache you use:
Today I needed a way to simply convert Punycode internationalized domain names to Unicode for proper display in UTF-8. I was hoping for some easy iconv magic but no such luck, PHP can’t even do part of it directly.
Googling for a bit I was only able to find one existing class that did this in pure PHP but it was well over 100k in size which was disturbing for my simple needs.
So I whittled it down to 50 lines or so and made some tweaks:
It can now handle in one function “multi-part” domains that have punycode in the sub-domain, domain and/or TLD.
ie. all the examples here work:
xn--r8jz45g.xn--zckzah is properly converted to
it also works with mixed domains, ie.
(you can only pass it the host part of the url, do not pass it the full URL with http or slashes or it will fail – use PHP’s parse_url to get just the host)
Note this does not do any sanitizing or other thorough checks or fixes – if you need that functionality (ie. raw user input from unknown sources) you’ll probably need the original full class over here:
As excited as I was to see the performance benchmarks for PHP 5.3.0
I am glad I resisted temptation and waited a little bit longer.
PHP 5.3.1 is right around the corner, here’s the forthcoming RC1 announcement for August 13th (next Thursday) http://news.php.net/php.internals/45230
(and note “a final release by the end of August”)
and here is an evergrowing list of fixes that will be included:
Now I just need to make sure eaccelerator is up to speed on 5.3
update: presenting my very first firefox plugin!
Detects if any of several session types are in use on a website. It has some room for improvement but the fact that it works at all is good start…
I dislike the use of sessions to track users between web pages because it slows things down on active websites and if cookies are disabled, they can create a mess when they get appended to the URL. They are also useless across multiple servers if they aren’t stored in a common memory pool (memcached, etc).
Here are some common session names:
ASP uses “ASPSESSIONID”
PHP uses “PHPSESSID”
.NET uses “ASP.NET_SessionId”
JSP uses “JSESSIONID”
ColdFusion uses “CFID”
(let me know if you are aware of others)
I try to avoid using sessions in my bbPress plugins but there are two (Human Test & OpenID) where I’ve been too tired (aka too lazy) to come up with a complex way around them that would involve mysql tables, etc. However I try to make sure that sessions are not activated when not needed (in most cases, only during registration. But there is a popular third-party plugin that I’ve taken over ownership for (bb-topic-views) that uses sessions all the time when reading topics to prevent re-counting on multiple pages of the same topic.
(This is NOT an issue if you just use filemtime once or twice on a page on the web. It’s just something I discovered after trying for an hour to debug a very large PHP script I wrote to process a great deal of data.)
filemtime is a “simple” function in PHP which just returns the date that a file was last modified. Sounds straightforward enough eh? Well if you are checking 1000 files, filemtime will actually DOUBLE the amount of time used if just reading the file with file_get_contents! Crazy right? Well the logic makes sense when you think about it. file_get_contents can be cached by the OS. filemtime cannot, because it assumed you need the newest, latest, uncached date fresh off the file to see if it was recently modified, even if you run the script twice, immediate after itself.
Besides the 15% speedup for most code (20% in some cases!) and reduced memory use, PHP 5.3 has some very interesting and handy features. Check out this really nice “slideshow” of what’s new in PHP 5.3 by Ilia Alshanetsky:
or in plain text (somewhat garbled as formatting is lost: (more…)