Phoronix has a new post to their blog sharing some benchmark results for PHP 7.3, the next major language release, and things are looking positive!

Released on Thursday was PHP 7.3 RC6 as the last planned pre-release for the upcoming PHP 7.3. Here are some benchmarks looking at the PHP 7.3 performance compared to PHP releases going back to the v5.5 series on a Linux server.

[...] I ran some fresh benchmarks over the past day on PHP 5.5.38, PHP 5.6.38, PHP 7.0.32, PHP 7.1.24, PHP 7.2.12, and the PHP 7.3.0-RC6 test release. [...] PHP 7.3 is just shy of 10% faster than PHP 7.2 in the popular PHPBench. PHP 7.3 is 31% faster than PHP 7.0 or nearly 3x the speed of PHP5.

The post includes more benchmarks that reinforce this same trend with both the Zend performance testing and their own testing framework.

Overall, PHP 7.3 is shaping up to be another notable upgrade to the PHP7 series for its continued performance improvements, the new PHP FFI interface, and other new additions for this PHP release due out in early December.

There's several ways to run PHP on various webservers out there and in a tutorial from the CloudWays blog they focus on one: using PHP-FPM and the performance gain it can give.

Speed matters. Our engineers are always looking at ways on improving the stack. One of the major objectives of our stack integrations is to improve the speed of the overall processes of our stack.

Keeping up with this practice, in a bid to increase speed of aspects of Managed Cloud Hosting coupled with constant improvements based on users feedback, Cloudways has now integrated PHP-FPM in all its servers. Owing to this integration, applications hosted on Cloudways servers are now going to perform up to 3x faster.

The post starts with a look at why to choose PHP-FPM and shares some benchmarks of it in use versus the more typical mod_php shared module. It then gets into the implementation steps, linking to a step-by-step guide on how to implement it.

In a new post Larry Garfield suggests and interesting approach to arrays in PHP: stop using associative arrays (or at least "basically never").

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

He starts by describing his test environment (a local environment, not a cloud one) and the code for his baseline tests. The code generates an array of one million items where each item is an associative array of an integer/string combo. He wants to see what kind of memory consumption is involved in the creation and processing of this data set via sorting. His second test evaluated the serialization size (again, code provided) again checking the memory consumption. He shares the results of these tests and then moves on to similar tests on:

• stdClass instances
• objects with public properties
• objects with private properties
• anonymous classes

The post ends with a summary showing the results of all tests side-by-side with some interesting results (but you'll have to check out the post for yourself if you want to see those).

The Kinsta blog has published an article they call the Definitive PHP 5.6, 7.0, 7.1, 72. and HHVM benchmarks providing a comparison between these different versions running different popular PHP software (including WordPress, Drupal and Magento 2).

Each year we try and take a deep dive into performance benchmarks across various platforms and see how different versions of PHP and HHVM stack up against each other. This year we went all out and benchmarked four different PHP engines and HHVM across 20 different platforms/configurations; including WordPress, Drupal, Joomla!, Laravel, Symfony, and many more. We also tested popular eCommerce solutions such as WooCommerce, Easy Digital Downloads, Magento, and PrestaShop.

[...] The results this year have drastically changed from our previous benchmarks where HHVM was the winner. We now are excited to see PHP 7.2 as the leading engine in terms of speed. [...] This is great news for developers and end-users alike as it means more of a focus back on PHP and providing faster websites and web services for everyone.

The post then starts with a look at the system setup (well, Google Cloud instance) that's used for the testing and how it is configured. From there it goes into the test results from each of the different types of software:

• WordPress
• Drupal
• Joomla!
• Magento 2
• Grav CMS
• October CMS
• Laravel
• Symfony
• PyroCMS
• Pagekit
• Bolt
• AnchorCMS
• PrestaShop
• CraftCMS
• ForkCMS

As you can see there's more of a leaning towards content management and e-commerce solutions in their list. It's good to see base frameworks in the list too, however. For each item in the list they provide a graph of the results showing requests per second.

On the Forma-Pro.com blog there's a new post from Maskim (their Chief Architect) comparing PHP AMPQ libraries including some benchmarks of their performance of their handling of messages.

Increasing popularity of AMQP interop prompted a wave of questions regarding which adapter is the fastest. In this post, I am going to share my findings of message publishing performance. There will be a similar post about consumption side.

He compares three of the main libraries: php-amqplib, amqp-ext and bunny (as well as their adapters for interoperability). To get a good comparison he's also thrown in one written in Golang for external comparison. He start be outlining the system specs he used for testing and then various graphs of the benchmark results. The results of his benchmark script are interesting with only a few oddities here and there. The post finishes with a summation of the results but you'll have to head over there to see those results.

In a quick post to his site Fabien Potencier (of Sensio Labs and the Symfony framework) has a post sharing some information around the performance of Symfony 4 and what kind of speed you can expect in your applications based on it.

Performance is an interesting and sensitive topic. Suffice to say that most projects should not care too much; modern PHP frameworks are fast enough for most use cases and projects. And PHP 7 performance improvements help a lot as well. But people like to compare frameworks, and I guess performance is one way to do so.

What about Symfony 4? During its development cycle, we did some nice performance optimizations: mainly to improve the router and container speed. But several non-related changes in Symfony 4 also help with performance... Your mileage may vary depending on your specific project of course.

He talks about some of the testing and evaluation that's already been done on "Hello world" script performance but points out that this isn't a very real world situation. He shares these metrics, however, to at least give a baseline to compare it against previous Symfony versions. The post also links to another resource that shares these and other benchmarks related to various PHP projects.

On the Symfony Finland site there's a new post sharing the results of some recent benchmarks of the differences between running the framework on PHP 7.1 and PHP 7.2:

PHP 7.2 will be launching soon, in fact, it has already reached Release Candidate status. I was exploring Symfony Flex with Docker setup and thought I would do a quick round of tests to compare the differences in PHP 7.1 and 7.2 (RC4) regarding performance with a few benchmarks.

[...] The benchmarked application is the Symfony Flex port of the hybrid application I did back in January. The project now has the required configuration to run it with Docker, and you can find the full source on GitHub.

The post then shares some of the results and conclusions of the test runs, showing the differences between the two versions. In one set of tests, they're calling the front page controller with Twig rendering and in the other a backend controller without the display rendering. PHP 7.2 ends up performing slightly better than PHP 7.1 overall but not by very much in most cases. The more dramatic change is on the backend, though, with a good jump in performance for a Symfony Flex application.

On the Symfony Finland site they've posted a retrospective about moving an application from Symfony 3 to Flex including the work that was done in the switch and the performance of the result.

Earlier this year I did some experimenting with a Hybrid state object between Symfony Twig templates and front end JavaScript frameworks. Since that time I did that experiment, the Symfony Flex project has progressed. I thought I would try how to port the state prototype to Symfony Flex.

[...] In my case the application was rather simple and all built in the AppBundle, which is best-practise in Symfony3 for many applications. I mostly had to move files and configurations around and change namespaces.

He starts by spending some time talking about the difference between a Symfony 3 environment and the environment Flex provides. He then goes through the eight or so steps to move from one to the other including file/directory changes and configuration updates. Next comes the look at performance differences between the two. Unsurprisingly Flex came out on top in every measurement he threw at it.

In addition to the new structure, the apparent improvement in performance is obviously welcome. This would likely be even more evident where I could leave more dependencies out, for example in API workloads. This obviously won't magically push Symfony/PHP into Golang or Node.js territory for raw API throughput, but for existing large code bases it could provide a low-effort boost.

The CloudWays blog has posted an article sharing the results from some benchmarking they've done comparing Laravel 5 on PHP 5.6 versus PHP 7.

Laravel is rapidly becoming a popular choice for PHP projects. The framework has established its reputation after the release of version 5.x. In the same vein, PHP recently received a major update in the form of PHP 7.1.x.

It is an established fact that Laravel has a solid codebase and provides optimized performance for all lightweight and enterprise level applications. However no statistics about Laravel 5 benchmarks and its performance with PHP 5.6 and PHP 7 are widely available.

Using the Blitz testing tool and sample Laravel applications managed through CloudWays (on DigitalOcean), they benchmarked mean response times and the "hit rate" of the requested pages. Graphs are included of the results for both PHP 5.6 and PHP 7 and the post ends with a comparison of the results from the two scenarios with PHP 7 coming out on top.

The Delicious Brains has a new tutorial posted sharing a method you can use to setup microcaching in Nginx for your WordPress installation and improve the performance of server requests by a large margin.

We’ve talked a lot about WordPress performance and hosting WordPress here at Delicious Brains. A common theme amongst those articles is the importance of page caching and how it’s arguably the best way to improve the performance of your WordPress site. [...] However, we’ve also alluded to the fact that page caching is difficult to implement on highly dynamic sites.

[...] In these circumstances page caching still has its place but the duration of the cache has to be significantly reduced. This is known as microcaching. Microcaching is a technique where content is cached for a very short period of time, usually in the range of 1-10 seconds. In this article, I’m going to demonstrate how to configure WordPress and bbPress with Nginx FastCGI caching.

They start off with some initial benchmarks performed using the Blitz.io service against a clean WordPress install on a Digital Ocean droplet. The first results are of a test with 100 concurrent users over 60 seconds (with not so great results). Then, using this method in the Nginx configuration, the site is retested resulting in much better performance but with one downfall - the pages are cached and no longer dynamic.

To resolve this they move to the "microcaching" solution, adding the caching to parts of the application that aren't the forum using the "X-Accel-Expires" header sent from WordPress. The post ends with a bit more tweaking to the configuration and some caveats to its use.