Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Freek Van der Herten:
Using Varnish on a Laravel Forge provisioned server
Jan 05, 2017 @ 14:19:15

Freek Van der Herten has a post to his site showing you how to set up Varnish with a Laravel Forge server. Forge is a service that makes it simpler to set up and manage servers and the applications installed without having to mess with the details yourself.

For a project we’re working on at Spatie we’re expecting high traffic. That’s why we spent some time researching how to improve the request speed of a Laravel application and the amount of requests a single server can handle. There are many strategies and services you can use to speed up a site. In our specific project one of the things we settled on is Varnish. In this post I’d like to share how to set up Varnish on a Forge provisioned server.

He gives a high level overview of what Varnish is and what benefit it provides to your application (complete with illustrations) and includes a link to a presentation introducing Varnish to PHP developers. Then he moves on to installing Varnish on the server, updating the VCL configuration file and opening a port for you to use when connecting to the Varnish service. He shows the difference in the response headers when Varnish handles the response and the updates you'll need to make to get your Laravel application to play nicely with Varnish with this package.

He ends the post with examples of how to test the performance difference and some final steps to update the config and have it run on port 80 instead of the default 6081.

tagged: laravel forge varnish provision server tutorial setup configure performance

Link: https://murze.be/2017/01/varnish-on-a-laravel-forge-server/

Toon Verwerft:
Optimizing PHP performance by using fully-qualified function calls
Dec 22, 2016 @ 12:27:55

Toon Verwerft has a post on his site with details about a micro-optimization you can use in your PHP application by using fully-qualified function calls, specifying the namespace even for root level PHP functions.

Today, a little conversation on Twitter escalated rather quickly. Apparently PHP runs function calls differently depending on namespaced or non namespaced context. When calling functions in a namespaced context, additional actions are triggered in PHP which result in slower execution. In this article, I'll explain what happens and how you can speed up your application.

The conversation started with [this tweet]. To understand the difference between global and namespaced function calls better, I'll explain what is going on under the hood.

He starts with this "under the hood" functionality, showing an example of a user-defined, root level function and the opcodes that result. He compares this to the opcodes generated when a namespaced function is called and the extra checking that goes into it (including checking both the namespace and the root levels). Another tweet implied that, because of this difference in checking, fully-qualified function calls would result in a performance increase. He set out to prove it as fact and used the phpbench tool to run four tests with various namespaced and non-namespaced examples. He includes the code he used for the testing and the results from a sample execution. There is, in fact, a slight performance gain from the fully-qualified version. He finishes up the post with some suggestions on using this knowledge including the root-level namespacing for built-in PHP functions.

tagged: performance optimize fullyqualified function call benchmark

Link: http://veewee.github.io/blog/optimizing-php-performance-by-fq-function-calls/

Blackfire.io Blog:
PHP 7 performance improvements (5 Part Series)
Dec 13, 2016 @ 11:54:21

The Blackfire.io blog has just wrapped up their series of posts covering some of the performance improvements that came along with PHP 7. In each post of the series they get into detail on one area, sharing some brief code samples and screenshots from the service showing the performance different between PHP 7 and PHP 5.

Julien Pauli, PHP contributor and release manager, details what changed between PHP 5 and PHP 7, and how to migrate and make effective use of the language optimizations. All statements are documented with specific examples and Blackfire profiles.

The topics covered are:

While some of the examples are (sort of) Symfony related, they're mostly about generic language level features and include some other considerations to think about when using the feature and the performance impact on your application.

tagged: blackfireio php7 performance improvement series

Link: https://blog.blackfire.io/category/tech

Blackfire.io Blog:
PHP 7 performance improvements (1/5): Packed arrays
Nov 17, 2016 @ 11:06:53

On the Blackfire.io blog a new tutorial has been posted by Julien Pauli looking at some of the features of PHP 7 and how they relate to the overall performance in this latest major version of the language. In this first post in the series Julien talks about packed arrays.

This blog series will show you what changed inside the Zend engine between PHP 5 and PHP 7 and will detail how you, as a developer, may effectively use the new internal optimizations. We are taking PHP 5.6 as a comparison basis.

[...] Packed arrays is the first great PHP 7 optimization. Packed arrays consume less memory and are a bit faster in many operations than traditional arrays.

He gets into the specifics of how the packed arrays work, mentioning the internal optimization the language does, requiring no intervention in user-land code. He shows the difference between the PHP 5.6 performance and PHP 7 using the Blackfire.io tool - a difference of about a 70% gain.

tagged: php7 blackfire performance packed array feature optimize

Link: https://blog.blackfire.io/php-7-performance-improvements-packed-arrays.html

Tumblr Engineering Blog:
PHP 7 at Tumblr
Nov 11, 2016 @ 13:07:07

The Tumblr Engineering blog has a new post with details about how they made the switch to PHP 7 in their previously PHP 5 codebase (and some of the things they learned along the way).

At Tumblr, we’re always looking for new ways to improve the performance of the site. This means things like adding caching to heavily used codepaths, testing out new CDN configurations, or upgrading underlying software.

Recently, in a cross-team effort, we upgraded our full web server fleet from PHP 5 to PHP 7. The whole upgrade was a fun project with some very cool results, so we wanted to share it with you.

They start off with the timeline of events, starting with the original hackday project out through the final PHP 7 deployment in production less than a year later. They cover some of the testing methods they employed during the transition and the impact of the update on their application on request latency, CPU load and memory usage. They wrap up the post talking about some of the PHP 7-specific things they made use of in their update including anonymous functions and scalar type hinting.

tagged: tumblr php7 update php5 hackday project testing performance

Link: https://engineering.tumblr.com/post/152998126990/php-7-at-tumblr

Symfony Finland:
What's in store for PHP performance?
Oct 18, 2016 @ 10:20:51

On the Symfony Finland blog there's a new post looking ahead at what they see in store for PHP's performance in a post-PHP 7.0.x world.

PHP 7.0 made significant improvements in terms of performance and memory use for real applications. Many applications deliver twice the throughput with much less memory just without any changes to the application code.

But with networked API driven architectures individual response times are increasingly critical for end-user experience. Luckily, there are quite a few unbeaten paths for regarding PHP performance.

These other "unbeaten paths" they mention include a trend towards using asynchronous patterns and the use of application servers (long running PHP processes). There's also mentions of JIT (just in time) compilation, defined request and response objects and the improvement of other possible PHP runtimes.

tagged: language future performance improvement opinion

Link: https://www.symfony.fi/entry/whats-in-store-for-php-performance

Raphael Stolt:
Eight knobs to adjust and improve your Travis CI builds
Oct 11, 2016 @ 09:18:53

If you're a Travis-CI user, like many projects are, you'll find this new post from Raphael Stolt very interesting. In it he provides "eight knobs" you can use to improve your use of the service and optimize your test runs.

After having refactored several Travis CI configuration files over the last weeks, this post will provide eight adjustments or patterns immediately applicable for faster, changeable, and economic builds.

Suggestions in his list include:

  • Reduce git clone depth
  • Configure PHP versions in an include
  • Only do static code analysis or code coverage measurement once
  • Run integration tests on very xth build

For each item on the list he includes the updates you'll need to make to your .travis.yml configuration to enable/disable the feature.

tagged: travisci service performance improvement build top8

Link: http://raphaelstolt.blogspot.com/2016/10/eight-knobs-to-adjust-and-improve-your.html

Generating Code Coverage with PHPUnit and phpdbg
Sep 06, 2016 @ 12:36:23

In this post on his Medium page Elton Minetto shows how to generate the code coverage of your PHPunit tests with better performance using phpdbg.

In a previous post (in portuguese) I explained how to identify tests that are taking too long to execute. In this post, I’ll show you how to increase the performance of code coverage report generation using PHPUnit.

In the phpunit.xml file it’s possible to add configurations to generate reports related to the tests that are being executed. [...] In addition to changing the phpunit.xml file, to generate this information we also need to install the extension XDebug. However, by installing it we get a substantial decrease in performance.

He shows an example of the time difference in running the tests (about 1 minute without versus 22 with XDebug). He went looking for a better way and found this post talking about using phpdbg instead. He includes the "brew" commands to get everything you'll need installed and how to use phpdbg with your coverage calls rather than XDebug. However, as is pointed out at the end of the post, the results are slightly different but they're close enough to help you know what code to target next.

tagged: codecoverage phpunit phpdbg results performance tutorial

Link: https://medium.com/@eminetto/generating-code-coverage-with-phpunite-and-phpdbg-4d20347ffb45#.we2bst8uk

Dries Vints:
Two tips to speedup your Laravel tests
Aug 25, 2016 @ 09:15:48

In this recent post to his site Dries Vints shares two quick tips you can use to help speed up the execution of the tests for your Laravel application.

I've seen two different tips for speeding up your tests in Laravel in the past week and thought I'd share them with you. For me, they made a significant impact on the speed of my tests.

His two tips involve lowering the "cost" factor on the number of "rounds" the user password is hashed and the use of a pre-computed hash in your testing factories. These both help reduce the overhead needed, especially when working with tests that need to create the user every time. He includes code and reference links for more information about these two tips and applying them in your testing.

tagged: speed performance laravel test hashing rounds precomputed

Link: https://driesvints.com/blog/two-tips-to-speedup-your-laravel-tests/

Chema Garrido:
Speed test PHP vs Lumen vs Laravel
Aug 18, 2016 @ 12:08:53

Chema Garrido has written up a post sharing some results of a performance test (speed) between Lumen and Laravel also comparing it against Kohana and straight PHP.

I am working in the new EmailValidator!, and after developing the EU VAT API, I feel confident to develop it on Laravel Framework. But before we start… let’s test the speed of the stack.

I used my local computer a 8 cores i7 2ghz 8GB ram 512SSD. Apache2, PHP 7.0.8. Tested this test with siege 5 times for each and retrieved the highest.

The first part of the post shows the results in a tabular format but following this is the more detailed version, complete with the siege command executed and the code used. The results are interesting but seem to mostly fall into the real of micro-optimization as there's really not that much difference between the results (though the "Longest transaction" on the plain PHP code is an oddity).

tagged: laravel lumen performance speed test results framework

Link: https://chema.ga/speed-test-php-vs-lumen-vs-laravel/