On the Laravel News site Tim MacDonald has written up a post sharing some tips on how you can speed up your PHPUnit tests, making them easier to run and more useful during the development process.

Having a fast test suite can be just as important as having a fast application. As a developer, getting feedback quickly about the state of your code allows for a much quicker development turnaround. Here we are going to run through some tips you can implement today to make your tests run faster.

The example test suites have been made intentionally slow to simulate a broader set of tests and also to emphasize the improvements possible. Your real-world mileage may vary.

He makes recommendations around the use of ParaTest to run the tests in parallel, re-running only failed tests, grouping slow tests, lowering the password hash "rounds" count and disabling XDebug. Each item in the list includes instructions on what changes need to be made and screenshots of the results of the change.

The Laravel News site has a new tutorial posted showing how to speed up your PHP execution when developing with Docker by making use of the OPCache functionality.

If you’re on Docker for Mac or Docker for Windows, you might see some noticeable slowness and time to the first byte (TTFB) depending on your application’s setup. One of the most important things you can do to improve performance is enabling the OPCache module (regardless of the development environment). There are other things like volume caching (if possible), but OPcache is a win that you want in any environment you’re running PHP applications.

The tutorial starts by sharing a basic Opcache configuration, setting values for timestamp validation, memory consumption, and fast shutdown. These values are static and not very flexible so they change things up by making them able to be set as a part of the Docker build process. The post includes the changes you'll need to make to your Docker configuration to make this setup work in two ways: either copying the file in on build or making use of environment variables to set the configuration options at runtime.

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 recent post to the Hackernoon site, Sergii Shanin shares his take on the "PHP is dead" conversations and posts out there with the expected "Viva le PHP!" (long live PHP!) following it.

The fracas over Gutenberg and WordPress is the latest installment in the death of PHP. Take a deep breath everybody. Let’s ignore the trolls and take a look at what Mark Twain, Fidel Castro and PHP have in common?—?and more to the point, why PHP is still a reasonable choice for startups and small businesses.

t looks like ‘PHP is dead’ blog posts started cropping up in 2011 (let me know if you find older ones). If you search around Medium and the coding bootcamps that are popping up like mushrooms, the only common denominator is that everyone hates on PHP or simply ignores it. Apparently, it’s impossible to code in PHP with an oiled beard and ironic t-shirt while drinking overpriced coffee.

He shares two of the most wide-spread myths about PHP - that it's slow and that it can't scale - and dispels them. He then goes through some types projects where PHP "shines" including content driven websites and e-commerce sites. He shares some the "business sense" around choosing PHP, the perspective senior PHP developers bring to teams and projects, and the seeming "nine lives" of PHP.

Blackfire.io, the PHP performance profiling service, has announced a series of webinars aimed to help you learn more about the service and how it can help you get the most out of your code. These webinars are spread out all across the globe so anyone can attend at a timezone-appropriate hour.

Here's the list for the October and November sessions:

• [Getting Started with Blackfire (October 30th, 2018 – US Session)](Getting Started with Blackfire (October 30th, 2018 – US Session))
• Getting Started with Blackfire (October 30th, 2018 – European Session)
• Getting Started with Blackfire (November 6th, 2018 – US Session)
• Getting Started with Blackfire (November 6th, 2018 – European Session)
• Introduction to Blackfire (November 13th, 2018 – US Session)
• Introduction to Blackfire (November 13th, 2018 – European Session)
• Getting Started with Blackfire (November 20th, 2018 – US Session)
• Getting Started with Blackfire (November 20th, 2018 – European Session)
• Getting Started with Blackfire (November 21st, 2018 – Asian Session)

You can find out more about the contents of each sessions - "Getting Started with Blackfire", "Introduction to Blackfire" and "Automating Performance Testing with Blackfire" - by clicking on the link for the related event. If you're interested at all in improving the performance of your application, check one of these webinars out. Blackfire offers their "Hack" level of support to try out for free too so there's no reason not to give it a shot!

On the Delicious Brains site there's a new tutorial posted for the WordPress users out there sharing a case study of the performance impact of WP Offload S3 on the average page load time.

One of the great things about working at Delicious Brains is working on products that I use and love outside of work. I was a WP Migrate DB Pro customer well before joining the team and still use it daily on personal sites and side projects. However, I’ve not often had the need to use our other plugin, WP Offload S3 to offload site media files to Amazon S3.

The post starts with some of the background on why the author chose the WP Offload plugin in the first place and what features it provided. The tutorial then walks you through the installation process and how to have assets served up by Cloudfront correctly. It also includes some things you should consider when figuring out if this setup is for you. It then wraps up with some benchmarks of the results post-implementation, seeing a decrease of almost a second off of the previous page load time.

Frederick Vanbrabant has a new post to his site sharing some performance tips you can integrate into your PHP code to help improve its overall processing time. He also talks some about a few that are just myths and debunks them.

We’ve all been there before, you submit a pull request and moments later you get a comment like: “Hey you should use a native function here, they are so much faster” or “You can declare this final, that way we save some processing power”.

It’s great that we as developers keep an eye on this, but how true are these thing. And are they still a thing in newer PHP versions?

He goes through a list of ten tricks that have been widely shared and creates some simple benchmarks around their use:

• single versus double quotes
• JSON handling versus XML handling
• speed difference from using layered objects
• native array functions versus loops
• fetching an array item by quoted ID versus just ID
• performance difference of throwing exceptions
• impact of unused variables
• magic methods versus normal methods
• final versus non-final classes
• comments in code

For each of the items in the list he includes the example code he used for the benchmark and the output from the PHPBench tool.

The SitePoint PHP blog has posted the latest tutorial in their series creating a simple image gallery application with a focus on performance. In this latest article they cover the use of Varnish for output and page caching.

According to Pingdom.com, a company focused on web performance, in 2012 Varnish was already famous among the world’s top websites for its capacity to speed up web delivery.

[...] Although there are other solutions that also shine, Varnish is still a go-to solution that can dramatically improve website speed, reduce the strain on the web application server’s CPU, and even serve as a protection layer from DDoS attacks. KeyCDN recommends deploying it on the origin server stack.

Varnish can sit on a dedicated machine in case of more demanding websites, and make sure that the origin servers aren’t affected by the flood of requests.

The article starts by explaining a bit about how Varnish (and caching in general) works to help improve the performance for the end user. It also goes through some of the basics feature of Varnish including threaded executions, extensibility and its domain-specific language. The tutorial then walks you through the installation of Varnish on a linux-based machine and shares some example stats showing the difference between normal requests and when Varnish is enabled for the image gallery application.

The SitePoint PHP blog has continued their series covering the creation of an online image gallery application. The series has included several tutorials covering performance and optimization improvements. In this latest article they continue that trend focusing on optimizing the resizing of the images.

We’ve been building a sample application — a multi-image gallery blog — for performance benchmarking and optimizations. At this point, our application serves the same image regardless of the resolution and screen size it’s being served in. In this image resizing tutorial, we’ll modify it to serve a resized version depending on display size.

They start by listing out the requirements for the improvement: make all images responsive and the addition of the code to generate the resized image. Next it discusses the state of responsive images on the web and shows the first additions to the templates for the "srcset" value. They create some helper methods in Twig to get the image URL and "srcset" value. Next up, the tutorial helps you install the league/glide package and use it to create a script to manually "serve" the resized image information back to the user.