Developing with Laravel is an efficient and enjoyable experience. Often, when you are ready to deploy an application, you may realize that the application may not perform well in the real world.

To be clear, there is no silver bullet. By trying to get all the polish done for every detail of your application, it can be slow, but using these tips will make you feel just right.

Cache configuration file

Laravel’s configuration items are distributed across dozens of configuration files, and including each file in each request is a performance drain. To combine all configuration files into one, use:

php artisan config:cache
Copy the code

The routing cache

Routing is also expensive in Laravel. Cache the routes.php file with the following command:

php artisan route:cache
Copy the code

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

php artisan route:clear
Copy the code

Class map loading optimization

In a mid-sized project, it’s not unusual to have hundreds of PHP source files, but as a matter of good programming practice, we tend to separate the code a bit, and each PHP file has its own responsibilities. Of course, this is not without its drawbacks; Laravel has to load hundreds of files for every request, which can be a performance drain.

Therefore, it is a good idea to declare which files the user needs to load with each request (service provider, middleware, etc.), and then reduce the number of include files by writing those files to the same file each time.

This is similar to javascript merging files into one indistinguishable (webpack, gulp), which reduces requests to the browser server.

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

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

php artisan optimize --force
Copy the code

Optimize automatic loading of Composer

This applies not only to Laravel, but to any application that uses Composer.

I’ll first explain how the PSR-4 autoloader works, then show you what commands you should run to optimize it. If you are not interested in learning how Composer works, I suggest you skip to the paragraph about 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 associative array of classes and files. Of course, because you did not manually add the Login class and its associated files to the class map, Composer will continue to search in the namespace.

Because App is a PSR-4 namespace that comes with Laravel by default and is associated with App/folder, Composer will attempt to convert the PSR-4 class name to a filename using basic string manipulation procedures. 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 just to get the App/Controllers/AuthController class exists in 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
Copy the code

Remember, if you’ve already run PHP Artisan Optimize — Force, you don’t have to run this function anymore. Because the optimization command has told Composer to create an optimized autoloader.

JIT compiler (just-in-time compiler)

PHP is not naturally understood by computers. You can’t just compile it into bytecode and have the computer run. PHP must go through a mediation, such as the Zend engine, which interprets the PHP file and executes the corresponding C routines. As you can imagine, it’s very slow. Every time your server executes a PHP file, it must convert it into tokens — this 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, run for life method, and that’s what a JIT compiler does.

The recommended JIT compiler for Laravel is HHVM, which was created and widely used by Facebook. Wikipedia, Etsy and thousands of other projects also use it.

Use faster caching and session drivers

Keeping sessions in files is a fast and elegant way to do this, and it has been done since the beginning of PHP. But if you’re looking for performance, the file system is one of the things you need to pay attention to because it’s slow. A better approach is to store caches and sessions in memory, because it provides an efficient way to read and write data. Fortunately, Laravel supports several memory-based cache and session drivers.

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

To change the session driver, check the “Driver” item in the following files:

app/config/session.php
Copy the code

To change the cache driver, check the driver item in the following files:

app/config/cache.php
Copy the code

Don’t underestimate the speed increase you can get by optimizing your query statements

As you can see, most optimizations use caching at different levels. But when it comes to database tuning, you shouldn’t rely on caching. Caching should be the last resort to optimize queries.

Caching query results

MySQL won’t do it for you, and it’s not as good as you can do it yourself. Of course, you don’t want to cache the results of every query in your application. If you look at statistics, what are the most frequent queries in your application that really need to be executed frequently? Wouldn’t it be better to run it every 15 minutes and provide the same results to the user?

Removing the removing method from the query constructor is a good thing (it used to be a good feature, but not good enough – people seem to overestimate its usefulness). Then you can use the Cache:: Remember method more often, like this:

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

{

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

});
Copy the code