Ben Sampson has a tutorial posted to his site for the Laravel users out there sharing some tips about speeding up your database queries when using relationships between models.

Adding indexes to your database tables is a great way to get some extra performance out of your application, especially if you have a large amount of data in your tables. They should be used sparingly and only on identified slow queries, as they have implications of their own such as increased table size and increased RAM usage. But those potential drawbacks are well worth it when you can get a query down from a 3 seconds 15 milliseconds with 5 minutes of work. The effects are particularly noticeable on polymorphic / many to many polymorphic relationships.

He then includes the code required to create the indexes on your tables (either a single column or a compound index involving more than one column) in your migrations. He also provides code examples showing how to use foreign keys to improve one-to-one/one-to-many relationships. More examples include optimizations for many-to-many relationships and polymorphic relationships.

On the SitePoint PHP blog they've posted a tutorial that continues their series covering the creation of a simple image gallery blog application. In this latest part of the series the author covers the use of the Blackfire.io service for performance testing.

Throughout the past few months, we’ve introduced Blackfire and ways in which it can be used to detect application performance bottlenecks. In this post, we’ll apply it to our freshly started project to try and find the low-points and low-hanging fruit which we can pick to improve our app’s performance.

If you’re using Homestead Improved (and you should be), Blackfire is already installed.

While it’s useful to be introduced to Blackfire before diving into this, applying the steps in this post won’t require any prior knowledge; we’ll start from zero.

The tutorial walks you through some of the basics of Blackfire and what kind of information it will report back. After a small change to the Homestead YAML configuration, they show how to profile the landing page and what the resulting graph looks like. It then goes through the code, finding each of the pain points and refactoring them to improve performance.

On the SitePoint PHP blog they've posted a tutorial from author Tonino Jankov sharing some techniques you can use to increase the performance of Apache and Nginx when serving up your web applications.

The article starts with some of the basics, introducing both the software and some of the concepts around their use and evaluation:

• an introduction to Apache and Nginx
• hardware considerations
• monitoring
• testing the systems (benchmarking)

It then starts on the tuning tips, one section for each of the web servers. For Apache it covers changes for the mpm modules, disabling htaccess and browser cache control with mod_expires. On the Nginx side, they mention changing the number of workers created, tuning the keepalive timout and setting up server-side caching.

In a post to his site Colin O'Dell shows how he used the Blackfire.io service to optimize the colinodell/json5 package he created to parse JSON5 in PHP. Blackfire.io is a performance profiling service (from the folks behind Symfony) that shows where the pain points are in your code. They also have a "developer" plan that you can use to try out the service.

Back in November, I released colinodell/json5 - a JSON5 parser for PHP. It's essentially a drop-in replacement for PHP's json_decode() function, but it allows things like comments, trailing commas, and more.

Fast forward to this weekend when I received [a] bug report from a user named Antonio [about slowness in parsing large JSON documents]. Yikes! I always knew that a PHP-based implementation would be slower than PHP's native C implementation, but execution time measured in minutes was completely unacceptable!

So I fired up Blackfire (which I've previously used to optimize league/commonmark) and got to work.

He starts off by getting a baseline to work from, executing the parsing on a custom document he created (not quite as large as in the bug report but still large). After locating a few issues he then started in on the optimizations. The first was an issue with the use of mb_substr, the second was around the remainder of the document to parse and the last an optimization for a regular expression. The post ends with a few other micro-optimizations he also made to the package and a check to use json_decode for faster parsing and only kick in the JSON5 parsing when needed.

On the SitePoint PHP blog Bruno Skvorc has a post that offers some helpful advice about optimizing your MySQL database through the use of indexes, monitoring slow queries and configuration options.

MySQL is still the world’s most popular relational database, and yet, it’s still the most unoptimized – many people leave it at default values, not bothering to investigate further. In this article, we’ll look at some MySQL optimization tips we’ve covered previously, and combine them with novelties that came out since.

He starts off with the configuration changes that can be used to optimize the database, tweaking settings for Innodb pool, handling variable inspection and using a tuning tool to determine the best settings. Next up comes the look at indexes covering the different kinds first: fulltext, descending, unique/primary and regular indexes. Finally he covers some of the usual bottlenecks seen in MySQL's use in web applications, showing how to monitor for them via the slow query log.

As this post to Laravel News mentions the upcoming v5.6 release of the framework will remove the artisan optimize functionality from the project's artisan command line tool.

The Artisan optimize command is deprecated as of 5.5, and a commit in master has already removed it from 5.6. Waiting until 5.6 gives you time to update your build scripts and composer.json files ahead of the release.

As of Laravel 5.5, the composer.json no longer references optimize in the post-install-cmd and post-update-cmd scripts. The Optimize command is still defined, but does nothing in 5.5.

The project has provided some reasoning behind the change, mostly having to do with the overall performance improvements in the PHP language itself. Additionally, there was some discussion around the removal before it was finalized.

On the Laravel News site they've posted a tutorial sharing some of the basics around the optimizing Eloquent queries with the help of its own "eager loading" feature.

Object Relational mapping (ORM) makes working with databases amazingly simple. While defining database relationships in an object-oriented way makes it easy to query related model data, developers might not pay attention to the underlying database calls.

A standard database optimization for an ORM is eager-loading related data. We will set up some example relationships and then walk through how queries change with and without eager loading. I like to get my hands directly on code and experiment with things, and I hope to illustrate how eager loading works with some examples will further help you understand how to optimize your queries.

They start with a classic example of the "N+1 problem" when working with database records and how, without you knowing, you might be causing it with lazy loading. The article then talks about eager loading vs lazy loading and how they differ in most ORMs. It then covers Eloquent, setting up some migrations for an example blog application and creating the relationships between Author (user) and the Posts. The models are created and seeders are built to populate the tables with Faker data. Finally it gets to the use of eager loading, making use of the "with" functionality to modify the query structure behind the scenes. The post finishes with mentions of two other eager loading types - lazy eager loading and nested eager loading.

In a continuation of his previous post about an image optimization package for PHP Freek Van der Herten covers some refactoring and advancements they've made to the package to make it even easier to use.

A while ago we released image-optimizer. In short this package can make all kinds of images smaller by stripping out metadata and applying a little bit of compression. Read this blogpost to learn more about it. Although it’s pretty easy to work with the package, we felt that we could deliver a more seamless experience in Laravel apps. That’s why we created our newly released laravel-image-optimizer package.

The package uses a bunch of binaries to optimize images. To learn which ones and how to install them, head over to the optimization tools section in the readme of the underlying image-optimizer package. That readme also contains info on <a href="https://github.com/spatie/image-optimizer#which-tools-will-do-what>what these tools will do to your images.

He then includes some code examples putting this new version of the package to work with a Laravel-based application. The examples include replacing the image with an optimized one, saving the optimized one to a new path and resize all images in a request. There's also an example configuration included showing the options you can set to customize your site's image optimization even more.

On the SitePoint PHP blog they've posted a tutorial about the Theory of Constraints, how it can be related back to PHP and what it means for building effective code.

I had been reading The Phoenix Project, a great novel about IT (you read that right), which presents day to day IT and devops problems at a large Amazon-like company in a way which makes mortals understand the complexities and chaos of 21st century technology.

Without giving away any spoilers, at one point in the book the Theory of Constraints is mentioned. [...] The Theory of Constraints can be distilled to the idea that the chain is only as strong as its weakest link.

In the book it was phrased thusly: "Any improvements made anywhere besides the bottleneck are an illusion." For some reason, this resonated with me much more than the chain idiom. There’s just something about building something that’s ineffective that’s more relatable to me than breaking something that’s weakly built.

He goes on to talk about the subject of "factories" and "browsers", relating work done (or not done) on browsers to a factory where throughput of work isn't optimized. He then applies this back to PHP, mentioning some of the tools that can help optimize your workflow to prevent the same kind of factory backlog. This list includes services like Blackfire, XDebug and MySQL optimization techniques.

Freek Van der Herten has a post on his site sharing a new package that's been developed to help optimize images using some PHP and a few other helpful tools.

Our recently released image-optimizer package can shave off some kilobyes of PNGs, JPGs, SVGs and GIFs by running them through a chain of various image optimization tools. In this blog post I’ll tell you all about it.

He starts off by talking about why they built the package - to make sure the images on their site were as optimized as possible - and what kind of tools are involved in making it work. Those tools are free to use but it does take a little manipulation to ensure the right data is being passed into each. He then gets into the code examples, showing how to optimize an image with just a few lines. The package determines based on the kind of image which optimizing tool to use. He also includes example code showing how to customize the optimization process with extra command line flags. Finally he includes an extra section showing how to integrate it with some of their other packages: the image package, laravel-medialibrary and Browsershot.