Posts tagged with performance
Over at Laravel News Mike Bronner wrote some tips on how to achieve an A+ rating for your HTTPS website.
Let’s take a few extra minutes to optimize your server and help it perform faster and be more secure. In this tutorial we will look at using SSL session caching, HTTP Strict Transport Security (HSTS), and Hypertext Transfer Protocol 2 (HTTP/2).https://laravel-news.com/2016/01/optimizing-ssl-laravel-forge/
The past few weeks we released several new packages: laravel-sluggable, laravel-robots-middleware, laravel-glide and pdf-to-text. These packages have in common that they all require PHP 7. Because there were several reactions and questions about this, I'd like to shed some light on that decision.
I expect that lots of developers will make the move to PHP 7 in the coming year. Sure there will always be legacy projects that'll never see an upgrade, but it makes no sense starting a greenfield project in PHP 5.X. The performance benefits are just too good. On the package side I expect that some widely used packages will make the jump as well. Jordi Boggiano has already announced that the next version of Monolog targets PHP 7. Also keep in mind that active support for PHP 5.x is coming to end this August (or at the latest December).
Not only developers will make a quick move to PHP 7. The speed benefit is quite interesting for hosting companies as well. A speedier PHP version means a machine can host more sites. There quite a few hosting companies that already made the jump and are offering PHP 7 support.
When we work on projects at Spatie we have to solve a lot of problems. When we solve a problem in way that the solution can be used in future projects, we create a package. So we create these packages primarily for our own future projects. We decided that from now on every greenfield project wil be a PHP 7 one. So it makes sense that our new packages would require PHP 7 as well. By doing so we can make use of the latest new features such as the scalar type hints, return types, anonymous classes and the null coalescing operator. At some point all our projects will leave PHP 5.6 behind. The earlier we won't have to deal with PHP 5.X code anymore the better.
I'm well aware that requiring PHP 7 will hurt the popularity of our packages in the short run. But popularity is not our main goal. People who are using the latest and greatest version of PHP can benefit from our work. And I hope others will be nudged a bit towards PHP 7 by our decision.
(EDIT: we won't change the requirements of our older packages. PHP 7 will only be required when we create a new major version.)
Join thousands of developers
Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.
No spam. Unsubscribe anytime. You can also follow me on X.
Povilas Korop shared a neat trick at Laraveldaily.com today.
Let’s imagine the situation: you have a big database table (like 10 000 rows or bigger) and you need to run an update to one column. But you cannot run just SQL query – there is some PHP logic behind it. So foreach loop could potentially take forever or bump into a default 30-second script limit. Luckily, Laravel has a neat solution for it.http://laraveldaily.com/process-big-db-table-with-chunk-method/
In this post, the Netflix Performance Engineering team will show you the first 60 seconds of an optimized performance investigation at the command line, using standard Linux tools you should have available.http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html
For the League's CommonMark parser, we chose to prioritize extensibility over performance. This led to a decoupled object-oriented design which users can easily and customize. This has enabled others to build their own integrations, extensions, and other custom projects.http://www.colinodell.com/blog/2015-11/optimizing-league-commonmark-blackfire-ioThe library's performance is still decent - the end user probably can't differentiate between 42ms and 2ms (you should be caching your rendered Markdown anyway). Nevertheless, we still wanted to optimize our parser as much as possible without compromising our primary goals. This blog post explains how we used Blackfire to do just that.
Another great article by Maxime Fabre:
In this article I'm going to dive into the pthreads extension (short for POSIX Threads). It has been around for a while (since 2012) but I feel like too many people forget it exists or assume it is going to be painful to use – mostly because the official documentation is rather slim about it.http://blog.madewithlove.be/post/thread-carefully/
Be sure to check out his previous post on Webpack and Blackfire too.
HTTP/2 has a great feature called server push. It enables the server to send multiple responses in parallel for one request. In a blogpost on the Symfony Finland blog Jani Tarvainen demonstrates how to make use of server push with the Symfony Kernel.
$app->get('/images'), function () use ($app) {
$images = array('/images/1.jpg','/images/2.jpg','/images/3.jpg');
$response = new JsonResponse($images);
foreach($images as $image){
$response->headers->set('link','<' . $image . '>; rel=preload; as=image',false);
}
return $response;
Read the entire article for some more background info.
The Retry library by Igor Wiedler has only 19 lines of code. Line 17 is a goto statement. In this issue on GitHub a user asks why Igor chose to use goto instead of resorting to recursion. Igor took the time to write out the reasoning behind that decision. It's a very interesting read on the PHP compiler and opcodes.
Why hello! Thank you for asking this most excellent question!https://github.com/igorw/retry/issues/3I have indeed considered alternatives to the goto. I have evaluated them to a great extent, and I am happy to present the results to you here.
Jake Archibald, a developer advocate for Google Chrome, wrote an excellent article on how modern browsers can handle responsive images.
https://jakearchibald.com/2015/anatomy-of-responsive-images/
A typical request on an dynamic PHP site can do a lot of things. It's highly likely that a bunch database queries are performed. On complex pages executing those queries and hydrating them can slow a site down.
The response time can be improved by caching the entire response. The idea is that when a user visits a certain page the app stores the rendered page. When a second request to the page is made, the app shouldn't bother with rendering the page from scratch but just serve the saved response.
I've made a Laravel package named "laravel-responsecache" that does just that. Installing it is very easy: just add the service provider and facade to the app's configuration. And step two is... there is no step two. In most cases you're done. All successful responses (that is a response with a statuscode in the 200 or 300 range) to a GET-requests will now be cached for a week. If the response of a specific route or controller should never be cached middleware can be added that prevents caching. Furthermore each logged in user will have have it's own separate cache. Cached responses can be stored in any configured repository in Laravel. You could easily share a cache between servers by using memcached.
I think that behaviour will suit a lot of use cases. If you need some other caching behaviour (eg. cache error responses, exempting redirects, using a common cache for users with the same role, changing the expiration time of the cache) you can easily write a custom caching profile.
The package isn't supposed to sweep performance troubles under the rug. All apps should be optimized so that they'll respond in an acceptable timeframe without using response caching. My rule of thumb is that typical pages in a cms should be able to render within a second (and preferably much less). Anything above that is unacceptable. That number is by no means scientific. Make up your own mind what an acceptable responsetime should be. Of course all of this depends on the type of site and the amount of visitors it has to handle. Also keep in mind that that there are a lot of other aspects that need to be considered when trying to deliver a speedy experience.
There are some great alternatives to cache responses. Two well known solutions are Varnish and Nginx caching. They take response caching one step further by not even invoking php when serving a cached request. Both options are very robust and can work on any scale. The benefits the Laravel package has over Varnish-like solutions is that it is easier to set up and that application logic can be used to determine what needs to be cached.
If you're interested in speeding up your Laravel app using the package, go take a look at it on GitHub:
HTTP2 will mean a change in how we should build websites. The best practices of HTTP1 are harmful in a HTTP2 world.https://mattwilcox.net/web-development/http2-for-front-end-web-developers
Michael Maclean demonstrates how a 2100% performance gain can be achieved when rendering a Mandelbrot fractal using Recki-CT, a PHP compiler written in PHP.
Recently, Anthony Ferrara (known throughout the Internet and beyond as @ircmaxell) and Joe Watkins (similarly well-known as @krakjoe) have been working on a new set of toys for solving this problem while staying on the “standard” PHP runtime. Recki-CT is a set of tools that implement a PHP compiler, in PHP. While this might you think of things like PyPy, which implements a Python virtual machine in Python, this is not Recki’s goal – it doesn’t provide a VM, so it can’t run PHP by itself. However, it can parse PHP code and generate other code from it.http://mgdm.net/weblog/php-at-the-speed-of-c/
This chart shows the number of requests per second that were performed (more is better). You can see that PHP 7 can do a lot more in comparison with the other versions. Response times drop from 0.2269 to 0.0865 seconds in the production environment.http://www.intracto.com/nl/blog/running-symfony2-on-php7
Nice benchmark-work by Tom Van Looy. It is clear that you'll benefit from impressive speed bumps when upgrading to the next major version of PHP. Tom also provides instructions on how to setup PHP7 so you can perform your own tests.
This is a "living document" in the sense that I keep posting updates, and I care about and value feedback, questions and comments I get about it. This document improves over time thanks to a joint effort.http://daniel.haxx.se/http2/
The DOM and all additional resources don't need to be parsed, the client can already begin the download of the `screen.css` resource, without "wasting time" processing the DOM and all external resources, only to make a new request to the server to begin fetching them.http://ma.ttias.be/service-side-push-http2-nghttp2/When you add this all up for all resources on a page, this can easily save 100-200ms of the total page load/paint of a website. Those are numbers that should really have you consider implementing HTTP/2.
Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
An old, but still relevant, blogpost by Derick Rethans (of Xdebug fame) about why the @-operator should be avoided.
http://derickrethans.nl/five-reasons-why-the-shutop-operator-should-be-avoided.html
Zend Framework 3 will be an evolution from ZF2, concentrating on simplicity, reusability, and performance.http://framework.zend.com/blog/announcing-the-zend-framework-3-roadmap.html
Optimizing for PHP7, and supporting PHP 5.5 seems like a good idea.
An overview of the hard- and software used by the StackExchange network to render 560 million pages views per month.