Php + opcache opcupid: presses the interface from 1200 ms to 180 ms

An emergency mission was received last week: the client feedback system was slow and the core interface response time exceeded 1,200 ms. Checked down and found that php was recomposing the code every time it was requested, and that opcache was nothing。

After a fine-tuning exercise, the response time for the interface was reduced from 1200 ms to 180 ms, with performance increased more than six times. Today we share the entire process of mapping and optimization。

Problem phenomenon

Client's php project runs on a 4 nuclear 8g server, laravel for frame. It's usually okay, it's on top of the peak, and the response time is over 1200 ms。

The first reaction is to check the database, and the result is that sql is fast and slow-search logs are clean and clean. And look at the cpu, the peak runs straight through。

Positioning problem: opcache not effective

With phpinfo() check, opcache does open, but look closely at the configuration:

I mean, i can't do that. I don't know what you're talking about# only 64mb
other organiser
# check file changes every time
i don't know, evencacheValidate freq=2 #2 second check once

Problem: the laravel project has tens of thousands of php files and 2,000 cache slots are not enough. Opcache's been phasing out the cache, which means it's not open。

Opcache's theory is simple

Php is an explanatory language, and each request is subject to: reading source code syntax analysis → syntax analysis compiled into opcode → execution。

The effect of opcache is to keep the compiled opcode in the memory. Next time, the request will be used directly。

However, if the cache space is insufficient, or documents are frequently checked for modification, the cache rate is low and performance is reduced。

Optimizing configuration

For the production environment, i have adjusted the following configuration:

; ram sufficient, laravel project proposal 256mb starting
i don't know what you're talking aboutNsuption = 256
;number of cache files recommended to set to 1. 5 times the number of project files
;find. -name "*. Php" |wc-l
i'm sorry, i'm sorry.
;time stamp validation of production environment and manual clearance of caches when deployed
i'm sorry.
;strings in memory, laravel uses much more
i'm sorry, i'm sorry.
;quick closing to speed up request closure
=1
;opening file caches and restarting php caches without loss
= /tmp/opcache

Clear cache on deployment

The code update will not take effect automatically after closing the valaidate timestamps. A line needs to be added to the deployment script:

# method i: restart php-fpm
php-fpm
# mode two: call opcache reset()
php-r "opcache reset"
# mode three: use carchetool (recommended)
cachetool opcache: reset-fcgi=/var/run/php-fpm. Sock

Optimizing effects

After adjusting the configuration, the effect is immediately visible:

How to monitor opcache status

This open source tool, recommended, can be found in real time in the project:

If you see a "cache full" or a hit rate of less than 95%, the configuration needs to be adjusted。

Common pit spots

1. Max accelerated files with maximum limit of 100,000, exceeding invalid

2. Development environment level

Docker environmental care opcache. File cache directory permissions

4. Cache each server when deployed

Summary

Php performance optimizes, opcache is the highest value for money. It is properly configured to increase performance several times easily and without changing a line of business codes。

Remember these key configurations: memory coNsuption large enough for max accelerated files, production environment closed。