How to build HHVM 3.22 master trunk on CentOS 7
HHVM 3.20, 3.21 and 3.22 are still faster than PHP 7.2 especially with many connections under load, however as of October 2017 there still are no official pre-compiled HHVM packages for CentOS 7.x so we need to revisit how to build it by hand, which is not too difficult, just takes most servers awhile to assemble
There are instructions on the HHVM wiki for CentOS7 but they are a year out of date now.
The process is straightforward, first we need to not only make sure we have all the libraries we need but also the development libraries and most recently a newer version of the GCC compiler, we will use GCC 6.3 found in the official SCL Devtoolset-6 for CentOS 7 (trusted because it is built by Redhat/CentOS)
PHP 7 Opcache adds Huge Pages support for extra performance
The PHP 7 opcache (open sourced by Zend, which replaced APC) gets a little performance boost from the added support of Huge Pages by Dmitry Stogov:
Added an experimental ability to move PHP code pages (PHP TEXT segment) into
HUGE pages.
; Enables or disables copying of PHP code (text segment) into HUGE PAGES. ; This should improve performance, but requires appropriate OS configuration. ;opcache.huge_code_pages=1
Note that PHP must first be compiled with the appropriate configure option:
./configure --enable-huge-code-pages (... etc.)
Essentially, Huge Pages (on OS that support them) reduces the size of the index that has to be searched to find allocated memory by allowing larger chunks of memory to be claimed instead of smaller blocks.
See the Debian wiki for a better explanation of huge pages:
https://wiki.debian.org/Hugepages
This will have to benchmarked to prove if it really enhanced performance and by how much (I suspect low single digits but everything helps).
Also new to PHP 7 will be a file-based cache for the opcache which can be used as either the primary or a secondary cache level: (more…)
PHP 5.4 reaches End-of-Life, PHP 7.0 release schedule filled, PHP 7.1 Branched
PHP 5.4 hit EOL yesterday (end of life). There will not be any further security updates for it. You should be using PHP 5.6 anyway, it is slightly faster.
http://php.net/supported-versions.php#layout-content
Meanwhile PHP 7.1 has now received its own branch and the rest of the release candidate schedule has been filled out on the timetable:
https://wiki.php.net/todo/php70#timetable
Sep 17 2015 PHP7 RC 3
Oct 01 2015 PHP7 RC 4
Oct 15 2015 PHP7 RC 5
Oct 29 2015 PHP7 RC 6
Nov 12 2015 PHP7 Final
So every other Thursday through November will bring more and more stability to PHP 7.0 which will be the most important PHP release since PHP 4
CURL broken in CentOS 7 / RHEL7 for past year
If you suspected maybe WordPress and other PHP apps were slower to ping/trackback sites and other fetches under CentOS 7 than CentOS 6, you aren’t imagining things.
Apparently libCurl (and therefore Curl in PHP) has been broken for over a year now without RedHat applying the available patch and pushing an update.
https://bugs.centos.org/view.php?id=8076
https://bugzilla.redhat.com/show_bug.cgi?id=1130239
patch: https://github.com/bagder/curl/commit/d529f388 (note July 2013)
PHP 7.0 Final will ship November 12th 2015
Very exciting to see the PHP team set the date for the PHP 7.0 final (gold) release.
https://wiki.php.net/todo/php70#timetable
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
WordPress 4.3 benchmark: HHVM 3.9 vs PHP 7.0
A casual Sunday morning benchmark for August 9th 2015 using latest builds:
1000 Front Pages of WordPress (virtually stock default install) HHVM 11.99, 11.83, 11.81, 11.78, 11.85 seconds PHP7 11.18, 10.95, 10.85, 10.96, 10.88 seconds
Using
WordPress trunk 4.3 RC2
HHVM trunk 3.9-dev
PHP trunk 7.0 RC1
(on CentOS 7)
(more…)
How to put MySQL functions back into PHP 7
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…
(more…)
Suhosin comes back from the dead, bringing security to newest PHP versions
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).
(more…)
PHP 5.4, 5.6, 5.7 WordPress 3.9 Benchmark
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
environment:
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
PHP 5.6 enters final beta, up to 10% faster than 5.4, 5.5
PHP 5.6 is about to enter its final beta this week or early next.
https://raw.githubusercontent.com/php/php-src/PHP-5.6/NEWS
It is now in “feature freeze” where only bug fixes will be applied to the code.
While PHP 5.5 was actually SLOWER than PHP 5.4 in some cases, it appears they have finally moved performance ahead with PHP 5.6 and informal benchmarks show it to be up to 10% faster than PHP 5.4 (and 5.5) using real-world code.
There will also be some further memory savings with how it handles strings and other data. Given the sheer size and bloat of modern WordPress, it will need every bit of help that PHP can throw at it, so I expect quick adoption on large websites.
Fortunately there are very few backward incompatible changes with PHP 5.6
The biggest “problem” will be deprecated warnings for users adapting to it from previous versions – but those warnings can be masked for now to reduce noise in error logs.
For example here is how I handle such noise on production servers via php.ini:
error_reporting = E_ALL & ~E_STRICT & ~E_DEPRECATED & ~E_NOTICE
The future of PHP looks quite exciting now with the recent proof-of-concept demonstrated via PHPNG (PHP next generation), where it might become 50% faster in some cases based on internal restructuring, memory handling modeled on jemalloc and just-in-time compiling. WordPress was already demonstrated to be 20% faster in an early experiment over PHP 5.5
Opcache Control Panel for PHP
With the first release of PHP 5.5 beta which includes the new Zend Opcache, I’d like to offer beta testers my free opcache control panel. It also works with PHP 5.4 and (in theory) 5.3
https://gist.github.com/ck-on/4959032/?ocp.php
or just right-click to download and save
PHP 5.5 to be delayed so Optimizer Plus can be built-in
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.
Free Control Panel for Zend Optimizer+ Opcache
In celebration of Zend open-sourcing their Optimizer Plus opcache for PHP, I whipped up a quick’n’dirty control panel just now. There doesn’t seem to be any other one? I wanted to learn and review its behavior a little more closely, to compare it to APC, Xcache and eAccelerator opcode caches.
github: https://gist.github.com/ck-on/4959032
(update: Version 0.0.4 now adds file grouping / sorting )
Code is a bit nasty in this early version because I did it in an hour. There is only limited info available about the cache state and I am still learning some of its caveats like it doesn’t actually store the file cached time but the file’s physical timestamp (probably to just see if the file has changed so it can recache it).
screenshot:
(more…)
How to manually install the Zend Optimizer Plus Opcode Cache on PHP 5.4
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.
(more…)
WordPress 10% faster with Zend Optimizer Plus vs APC opcode cache
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).
APC 3.1.14 opcode cache for PHP pulled
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…)
APC to be replaced by Zend OptimizerPlus with PHP 5.5 release
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.
https://wiki.php.net/rfc/optimizerplus
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 feature freeze February 7th, 2013 – : : – APC possibly doomed
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
Some progress in making Suhosin work with PHP 5.4
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…
What’s coming in PHP 5.3.22 and PHP 5.3 end-of-life
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).
(phpnet@lostreality.org, 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)
What’s new in PHP 5.4.9 (changelog)
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.
However suhosin unfortunately is not available yet for PHP 5.4
Here are the important bug fixes in PHP 5.4.9 (vs 5.4.8)
All I want for Xmas is Suhosin for PHP 5.4
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.
WordPress nearly 10% faster on PHP 5.4 than 5.3
The speed improvements in PHP 5.3 over PHP 4 were significant.
Now comes news of some additional improvements to squeeze out nearly 10% more performance:
WordPress desperately needs every ounce of help it can get as it grows more and more sluggish with every release, so this is helpful news.
Even faster APC PHP cache by turning off file stat
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:
(more…)
_ck_ says... 
