Detailed explanation of methods to improve Laravel application performance

Using Laravel for development is an efficient and enjoyable experience.
Usually, when you are ready to deploy an application, you may realize that the application may not perform well in the real environment.

It should be understood that there is no silver bullet. By trying to optimize every detail of the application, the speed may slow down, but using the following skills will make you feel just right.

Cache configuration file

The laravel configuration items are distributed in dozens of configuration files, and it consumes performance to bring each file including in every request. To merge all configuration files into one, you can use:

php artisan config:cache

Remember that modifying the configuration file will not affect the existing configuration file cache. To refresh the cache, you can repeat the above command. If you want to clear the cache completely, execute:

php artisan config:clear

Routing cache

In laravel, routing also requires expensive overhead. Cache the routes. php file with the following command:

php artisan route:cache

Note that it does not apply to closures. If you are using closures, this is a good opportunity to move them to the controller, because the artisan command throws an exception when trying to compile a path bound to the closure instead of the correct controller method.
As with the configuration cache, any changes to routes. php will have no impact. To refresh the cache, run the above command every time you change the path file. To completely clean up the routing cache, run the following command:

php artisan route:clear

Class mapping loading optimization

In a medium-sized project, it is normal to have hundreds of php source files. Due to good programming habits, we will do a little separation of the code, and each php file has its own responsibilities. Of course, this is not without its drawbacks. Laravel has to load these hundreds of files for every request, which is a very performance-intensive thing.

Therefore, a better way is to declare which files need to be loaded every time the user requests (such as service provider, middleware, etc.), and then write these files that need to be loaded every time into the same file to reduce the number of include files.

This is similar to javascript merging files into one without distinction (webpack, gulp), which will reduce the visitor's request to the server.

If additional source files need to be added, they can be declared in files key of config/compile. php.

When you set up the files that need to be loaded for each request, they will be written to the same file, reducing the performance consumption of loading files

php artisan optimize --force

Optimize the automatic loading of composer

This applies not only to laravel, but also to any application that uses composer.

I'll first explain how the PSR-4 auto-loader works, and then show you what commands to run to optimize it. If you are not interested in learning how composer works, I recommend skipping to the section on console commands.

When you request the App\ Controllers\ AuthController class from compsoser, it first searches for direct associations in the class map. classmap is a 1-to-1 associated array of classes and files. Of course, since you did not manually add the Login class and its related files to the class map, composer will continue to search in the namespace.

Because App is an PSR-4 namespace, provided by default with Laravel 1 and associated with an app/folder, composer will attempt to convert the PSR-4 class name to a file name using the basic string manipulation procedure. Finally, it guesses that App\ Controllers\ AuthController must be in the AuthController. php file, which is in the Controllers/folder, which happens to be in the Namespace folder, app/.

All this hard work is just to get that the App\ Controllers\ AuthController class exists in the app/Controllers/AuthController. php file. To have composer scan the entire application and create a direct 1-to-1 association of classes and files, run the following command:

composer dumpautoload -o

Remember, if you've already run php artisan optimize--force, you don't have to run this function anymore. Because the tuning command has told composer to create an optimized auto-loader.

JIT compiler (just-in-time compiler)

PHP is not naturally understood by computers. You can't compile it into bytecode and let the computer run. PHP must go through a mediation, such as the Zend engine, which interprets the PHP file and executes the corresponding C routine. As you can imagine, it is very slow. Every time your server executes an PHP file, it must be converted to tokens-a process that is done and interpreted by the AST parser. Unfortunately, the parser must compile the PHP file every time, even if it gets the same result every time.

To make your application faster, you need a compile-once, life-long method, and that's what an JIT compiler does.

The JIT compiler recommended for Laravel is HHVM, founded and widely used by Facebook. Wikipedia, Etsy and thousands of other projects are also using it.

Use faster caching and session-driven

Saving session in a file is a fast and elegant way to do it, as it has been since the days of PHP. But if you're looking for performance, the filesystem is one thing you need to pay attention to because it's slow. A better practice is to store cache and session in memory because it provides an efficient way to read and write data. Fortunately, the laravel supports a number of memory-based cache and session drivers.

My suggestion is to use memcached as the driver for cache and session, but you can choose whatever you like as long as it works on a memory-based basis.

To change the session driver, you need to check the "driver" entry in the following file:

app/config/session.php

To change the cache driver, you need to check the "driver" entry in the following file:

app/config/cache.php

Don't underestimate the improvement in query speed caused by optimizing query statements
As you can see, most optimizations use caching at different levels. But when faced with database optimization, you should not rely on caching. Caching should be the last resort to optimize queries.

Cache query results

MySQL won't do it for you, and it's not as good as doing it yourself. Of course, you certainly don't cache the results of every query in the application. Look at the statistics. Do those high-frequency query statements in the application really need to be executed frequently? Wouldn't it be better to run every 15 minutes and then provide the same results to users?

Removing the removing method from the query constructor is a good thing (it used to be a good feature, but it wasn't good enough-people seem to overestimate its usefulness). Then you can use the Cache:: remember method more, just like this:

$posts = Cache::remember('index.posts', 30, function()

{

return Post::with('comments', 'tags', 'author', 'seo')->whereHidden(0)->get();

});