Laravel application performance tuning

The optimization techniques used in this performance testing solution are mainly based on the Laravel framework itself and the tools it provides.

close application debugapp.debug=false

Cache configuration information php artisan config:cache

Cache routing information php artisan router:cache

Class map loading optimization php artisan optimize

Autoload optimization composer dumpautoload

Load only necessary middleware as needed

Use just-in-time compiler (JIT), such as: HHVM, OPcache

Using PHP 7.x

In addition to the above optimization techniques, there are many coding practices that can improve the performance of Laravel applications, which will not be explained in this article for the time being. (You can also follow my follow-up articles)

1. Turn off application debug

Open the .env file in the application root directory and set debug to false.

APP_DEBUG=false

2. Cache configuration information

php artisan config:cache

Running the above command can merge all configuration information in the config folder into a bootstrap/cache/config.php file, reducing the number of files loaded at runtime.

php artisan config:clear

Running the above command can clear the cache of configuration information, that is, delete the file

3. Cache routing information

php artisan route:cache

Running the above command will generate the file bootstrap/cache/routes.php. Route caching can effectively improve the registration efficiency of routers, and the effect is more obvious in large-scale applications.

php artisan route:clear

Running the above command will clear the route cache, that is, delete the file.

4. Class map loading optimization

php artisan optimize --force

Running the above command can merge the commonly loaded classes into one file, and improve the running efficiency by reducing the loading of files. This command will generate two files bootstrap/cache/compiled.php and bootstrap/cache/services.json.

The classes to be merged can be added by modifying the config/compile.php file.

In the production environment, the --force parameter file can also be automatically generated without specifying the --force parameter.

php artisan clear-compiled

Running the above command will clear the classmap loading optimization, which is to delete

5. Automatic loading optimization

composer dumpautoload -o

Laravel applications are built using composer. This command will convert PSR-0 and PSR-4 into a class map to improve class loading speed.

Note: This is already done in the php artisan optimize --force command.

6. Load only necessary middleware as needed

Laravel applications have a lot of middleware built in and enabled. Each Laravel request loads related middleware and generates various data. Commenting out unneeded middleware (such as session support) in app/Http/Kernel.php can greatly improve performance.

7. Use the Just-in-Time Compiler

Both HHVM and OPcache can easily improve the performance of your application by 50% or more without any modification.

8. Using PHP 7.x

It can only be said that PHP 7.x has a great improvement in performance compared to the previous version.

Well, limited to your real corporate environment, this may not change for a long time, so I didn't say it.

0x02 Test plan

We use simple Apache ab commands to test only the application entry file and log and analyze the data.

Only test the entry file index.php of the application, visit "/" or "/index.php" to return to the welcome page of the framework. More comprehensive performance testing requires testing against more interfaces of the application.

Use the Apache ab command. ab -t 10 -c 10 {url}. This command means that 10 requests are made to the url at the same time and lasts for 10 seconds. The specific parameter settings in the command need to be selected according to the performance of the server to be tested.

In order to avoid data errors caused by machine fluctuations, each test condition will execute the ab command multiple times, and record the command execution results, focusing on the number of requests processed per second and the request response time, and analyze and eliminate outliers.

Every time the test conditions are adjusted, you need to visit the welcome page on the browser to ensure that there is no access error due to the modification of the test conditions. If the page is accessed incorrectly, the test result will be wrong.

Server Environment Description

All test data out of context are meaningless and can only be compared under similar conditions.

This environment runs on a Mac, with 8G memory, 2.8GHz processor, and SSD hard drive.

The test server was built using Homestead. The virtual machine is configured with a single-core CPU and 2G memory.

The PHP version of the server is 7.1. If there is no special description, it indicates that OPcache is enabled.

The tested Laravel application was written in version 5.2. There are 85 routes defined in app\Http\routes.php.

During the test, except for the virtual machine, terminal and fixed browser window, there is no program running that will affect the machine.

The above data can be used as a reference for your own testing.

0x03 Test process and data

1. Without any optimization

1.1 Operation

Take the appropriate action according to the following check items.

run ab -t 10 -c 10 http://myurl.com/index.php

Basic check items

APP_DEBUG=true in the .env file

bootstrap/cache/config.php does not exist

bootstrap/cache/routes.php

bootstrap/cache/compiled.php和bootstrap/cache/services.json

Most of the middleware is enabled in app/Http/Kernel.php

Browser access to the Laravel application welcome page to ensure normal access

1.2 Data logging

2. Turn off application debug

2.1 Operation

On the basis of step 1, modify APP_DEBUG=false in the .env file.

Browser access to the Laravel application welcome page to ensure normal access.

2.2 Data logging

2.3 Comparison results

Compared with the results of step 1, it is found that after the application debug is turned off, the number of requests processed per second increases from 26-34 to 33-35, and the request response time decreases from more than 300ms to about 290ms. The effect is not obvious, but there are certain promote.

Note: This part has a relatively large relationship with usage such as logs in the application.

3. Enable cache configuration information

3.1 Operation

On the basis of step 2, run php artisan config:cache to confirm the generation

3.2 Data logging

3.3 Comparison results

Compared with the results of step 2, it is found that after the configuration information cache is enabled, the number of requests processed per second increases from 33-35 to 36-38, and the request response time decreases from about 290ms to about 260ms.

4. Enable caching of routing information

4.1 Operation

Based on step 3, run php artisan route:cache

4.2 Data logging

4.3 Comparison Results

Compared with the results of step 3, it is found that after the routing information cache is turned on, the number of processed requests per second increases from 36-38 to about 60, and the request response time decreases from 260ms to about 160ms. The effect is remarkable. From the perspective of TPS, it has increased by 70%.

5. Remove unnecessary middleware

5.1 Operation

On the basis of step 4, comment out unnecessary middleware code.

Note: I commented out all middleware for this test. In practical situations, only the necessary middleware should be left as far as possible.

5.2 Data logging

5.3 Comparison Results

Compared with the results of step 4, it is found that after removing unnecessary middleware, the number of requests processed per second increased from about 60 to about 90, and the request response time decreased from 160ms to about 110ms. The effect is very obvious. From the perspective of TPS, it has increased by 50%. %.

6. Enable class map loading optimization

6.1 Operation

Based on step 5, run php artisan optimize --force

6.2 Data logging

6.3 Comparison Results

Compared with the result of step 5, it is found that after the optimization of class map loading, the number of processing requests per second increases from 90 to 110, and the request response time decreases from 110ms to less than 100ms, and the effect is quite obvious.

7. Close OPcache

7.1 Operation

On the basis of step 6, close PHP's OPcache and restart the server. Confirm that OPcache has been closed via Zend OPcache of phpinfo().

7.2 Data logging

7.3 Comparison Results

Compared with the result in step 6, it is found that after closing OPcache, the number of requests processed per second drops from 110 to 15, and the request response time rises from less than 100ms to more than 650ms. There are several times the difference in data when OPcache is turned on and off.

After that, I reopened PHP's OPcache and the data was restored to the step 6 level.

0x04 Stepped pit

1. [LogicException] Unable to prepare route [/] for serialization. Uses Closure.

This error is reported when running the php artisan route:cache command.

Reason: The way of closure is used when processing "/" in the routing file. To run this command, the concrete implementation of the route cannot use the closure method.

Modification: Put the specific implementation of the route into the controller to implement.

2. [Exception] Serialization of 'Closure' is not allowed.

Cause: Duplicate routes are defined in the route file.

Modification plan: Check for duplicate routes in the routing file and modify them. In particular, note that the resource method is likely to cause duplication of its methods.

3. [RuntimeException] Invalid filename provided.

php artisan optimize --force naming times this error.

Cause: The corresponding file was not found when loading a class that needs to be compiled. The file path to be compiled is defined in vendor/laravel/framework/src/Illuminate/Foundation/Console/Optimize/config.php of version 5.2, but I don't know why /vendor/laravel/framework/src/Illuminate/Database/Eloquent/ ActiveRecords.php was not found, so this error was reported.

Modification: Temporarily comment out the line ../ActiveRecords.php in the above config.php.

4. InvalidArgumentException in FileViewFinder.php line 137: View [welcome] not found.

After php artisan config:cache, this error is reported on the browser to visit the welcome page of the Laravel application.

Reason: The Laravel application server is set up on a virtual machine via Homestead. And this command I ran outside the virtual machine, resulting in the path in the generated config.php being the local path, not the path on the virtual machine. So the view file cannot be found.

Modification: ssh to run the command inside the virtual machine.

0x04 Practical skills

The pit has also been stepped on, and the test has been done. Here is a brief summary of practical skills for this experience.

1. Effective Laravel Application Optimization Tips

(includes autoload optimization)

2. Considerations when writing code

The specific implementation of routing is placed in the controller.

Do not define duplicate routes, pay special attention to the resouce method.

Clarify the role of each middleware and delete unnecessary middleware references.

0x06 Next step

Reminder: The above tuning skills and coding precautions are mainly aimed at the framework itself. There are many specific optimization skills in real business logic coding, which are not discussed here.

Subsequent optimization will focus on specific coding practices:

Use Memcached to store session config/session.php

Use a professional cache drive

Database request optimization

Write caching logic for datasets

Front-end resource merge Elixir

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324740788&siteId=291194637