PHP-FPM configuration and usage summary, php-fpm configuration Summary

PHP-FPM configuration and usage summary, php-fpm configuration Summary

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.

 

PHP-FPM configuration and use summary:

PHP-FPM is a PHP FastCGI manager, which is actually a PHP source code patch designed to introduce FastCGI process management into PHP software packages, We must patch it into PHP source code, and then compile again to use. Now we can directly enable and use PHP 5.3.2 and later versions, because PHP has already included it in the software package, so it is no longer a patch package.

 

· Several concepts

· Nginx + PHP configuration

· Php-Fpm operations

 

I. Several Concepts

1) CGI

CGI is the Common Gateway Interface. It is an Interface for the HTTP server to communicate with programs on other machines. Its programs must run on the network server.

 

NOTE:

CGI can be written in any language as long as it has standard input, output, and environment variables.

 

2) FastCGI

FastCGI is a resident CGI that can be executed all the time. After being activated, it will not take time to fork every time (this is the most criticized fork-and-execute mode for CGI ). It also supports distributed operations, that is, FastCGI programs can run on hosts other than website servers and receive requests from other website servers.

FastCGI is a CGI open extension in a language-independent and scalable architecture. Its main behavior is to maintain the CGI interpreter process in the memory and thus achieve high performance. We know that repeated loading of the CGI interpreter is the main cause of poor CGI performance. If the CGI interpreter is saved in the memory and is scheduled by the FastCGI Process Manager, therefore, it can provide good performance and scalability.

 

Advantages:

1. FastCGI is language-independent;

2. FastCGI runs independently on core web servers and provides a safer environment than APIs. APIs links the application code with the core web server, which means that the application in a wrong API may corrupt other applications or core servers. Malicious API application code can even steal the keys of another application or core server;

3. Currently, FastCGI technology supports the following languages: C/C ++, Java, Perl, Tcl, Python, SmallTalk, and Ruby. Related modules are also available on popular servers such as Apache, ISS, and Lighttpd;

4. FastCGI does not rely on the internal architecture of any Web server. Therefore, FastCGI remains stable even if the server technology changes;

 

Disadvantages:

Because it is a multi-process, it consumes more server memory than CGI multithreading, The PHP-CGI interpreter consumes 7 to 25 MB memory per process, multiply this number by 50 or 100, which is a large amount of memory.

The Nginx 0.8.46 + PHP 5.2.14 (FastCGI) server consumes 30 thousand MB of memory (15 MB * 10 = 150 MB) for the 10 Nginx processes enabled with concurrent connections ), the 64 opened php-cgi processes consume 1280 MB of memory (20 mb * 64 = Mb). In addition, the system consumes less than 2 GB of memory. If the server memory is small, only 25 php-cgi processes can be started, so that the total memory consumed by php-cgi is 500 mb.

The above data is taken from Nginx 0.8.x + PHP 5.2.13 (FastCGI) to build a Web server that is 10 times better than Apache (version 6th ).

 

Principle:

1. When the Web server is started, load the FastCGI Process Manager;

2. FastCGI Process Manager initialization, starts Multiple CGI interpreter processes (PHP-CGI) and waits for a connection from the Web server;

3. When a client request arrives at the Web server, the FastCGI process manager selects and connects to a CGI interpreter. The Web server sends CGI Environment Variables and standard input to the FastCGI sub-process PHP-CGI.

4. After the FastCGI sub-process completes processing, the standard output and error messages are returned from the same connection to the Web server. When the FastCGI sub-process closes the connection, the request processing is complete. The FastCGI sub-process then waits for and processes the next connection from the FastCGI Process Manager (running on the Web server. In CGI Mode, the PHP-CGI exits here.

 

In the above cases, we can imagine how slow CGI is. Every Web request, PHP, must re-Parse php. ini, re-load all extensions, and reinitialize all data structures. With FastCGI, all of these occur only once when the process is started. In addition, persistent database connections can work.

 

NOTE:

FastCGI's main advantage is the dynamic language and HTTP Server separated, so Nginx and PHP/PHP-FPM are often deployed on different servers, to share the front-end Nginx Server pressure, enables Nginx to specifically handle static requests and forward dynamic requests, while the PHP/PHP-FPM server specifically parses PHP dynamic requests.

 

3) PHP-CGI

PHP-CGI is the FastCGI manager that comes with PHP.

Lack of PHP-CGI:

1. After changing the php. ini configuration of php-cgi, restart php-cgi to make the new php-ini take effect.

2. directly killing the php-cgi process, php won't be able to run (PHP-FPM and Spawn-FCGI won't have this problem, the daemon will generate a new child process smoothly ).

 

4 ),Spawn-FCGI

Spawn-FCGI is a common FastCGI management server. It is part of lighttpd. Many people use Spawn-FCGI of Lighttpd to manage FastCGI mode, but it has many disadvantages. While the emergence of PHP-FPM has mitigated some problems, but the PHP-FPM has a disadvantage is to re-compile, which for some already running environment may have a small risk (refer ), in php 5.3.3 you can use the PHP-FPM directly.

 

Spawn-FCGI has become a single project, which is more stable and convenient for the configuration of many Web sites. Many sites have already used it with nginx to solve dynamic web pages. The latest lighttpd does not contain this one either (http://www.lighttpd.net/search? Q = Spawn-FCGI), but it can be found in previous versions. In lighttpd-1.4.15

The version contains (http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz), which is currently available for Spawn-FCGI.

 

NOTE:

The latest Spawn-FCGI can search for "Spawn-FCGI" on the lighttpd.net website to find its latest release address.

 

5) Comparison of Spawn-FCGI

PHP-FPM is very convenient to use, configuration is in the PHP-FPM.ini file, and start, restart can be done from php/sbin/PHP-FPM. More convenient is to modify php. ini can be directly loaded using the PHP-FPM reload, without killing the process can complete the php. ini modification Load

The results show that using PHP-FPM can greatly improve php performance. PHP-FPM Control Process cpu recovery speed is slow, memory allocation is very even.

The CPU usage of the process controlled by Spawn-FCGI decreases rapidly, while the memory allocation is uneven. Many processes do not seem to be assigned, but others occupy a high volume. It may be caused by uneven process task allocation. This also led to a decrease in the overall response speed. The rational allocation of PHP-FPM leads to the mention of the overall response and the average task.

 

Ii. Nginx + PHP configuration

1. Process count Optimization

Pm = dynamic

Pm. max_children = 300

Pm. start_servers = 20

Pm. min_spare_servers = 5

Pm. max_spare_servers = 35

 

2. Optimization of the maximum number of requests

Pm. max_requests = 10240

 

NOTE:

This is used to handle memory leaks caused by the PHP parser or referenced third-party libraries.

Maximum number of requests: the number of requests processed by a php-fpm workflow that are terminated.

 

3. Maximum execution time optimization (php. ini)

Request_terminate_timeout = 20

 

NOTE:

This solution is used to handle 502 errors because PHP Execution time is too long.

This duration configuration can be configured either in php. ini (max_execution_time) or in the php-fpm.conf, which can be done in the php-fpm.conf without affecting the global configuration.

It is worth noting that the configuration should be combined with max_fail (greater) and fail_timeout (smaller) in nginx. conf.

 

Nginx. conf:

Location ~ \. Php $ {

...

Fastcgi_connect_timeout 180;

Fastcgi_read_timeout 600;

Fastcgi_send_timeout 600;

...

}

 

NOTE:

The maximum execution time of the script set by the PHP-FPM is long enough, but when executing the time-consuming PHP script, it is found that Nginx reports an error to 504. This is because we only modified the PHP configuration, and Nginx also had the configuration factcgi_connect/read/send_timeout for the communication timeout time with the upstream server.

 

4. php-fpm high cpu usage troubleshooting

Top command:

After running the top Command, enter 1 to view the CPU usage of each core:

 

Sar command:

Install the sar and iostat commands:

Sysstat. x86_64: The sar and iostat systemmonitoring commands

Yum install-y sysstat. x86_64

Run:

$ Sar-p all 100

 

NOTE:

-P all indicates monitoring ALL cores;

1 indicates collection every 1 second;

100 indicates that the data is collected for 100 times;

 

5. Enable slow log

Slowlog = log/$ pool. log. slow

Request_slowlog_timeout = 2

 

NOTE:

The above describes how to enable the slow log of php-fpm. The time threshold is 2 seconds;

 

Run:

Grep-v "^ $" php. slow. log | cut-d ""-f 3,2 | sort | uniq-c | sort-k1, 1nr | head-n 50

 

NOTE:

Sort: sorts words.

Uniq-c: displays a unique row and adds the number of times this row appears in the file to the beginning of each row.

Sort-k1, 1nr: sort by the first field, numerical value, and backward

Head-n 10: Get the first 10 rows of data

 

PS:

The purpose of enabling slow logs is to track and analyze the php script execution time that exceeds the set request_slowlog_timeout time. If the time exceeds the set time, the script will be recorded.

 

3. Php-Fpm operations

Php-fpm in PHP5.3.3 does not support commands such as/usr/local/php/sbin/php-fpm (start | stop | reload) in php-fpm, signal control is required:

 

The master process can understand the following signals:

INT and TERM terminate immediately;

QUIT smoothly terminates the termination;

USR1 re-open the logging file;

USR2 smoothly reloads all worker processes and reloads the configuration and binary modules;

 

Example: Example:

Php-fpm close: Unlock kill-INT 'cat/usr/local/php/var/run/php-fpm.pid 'then'

Php-fpm restart: restart kill-USR2 'cat/usr/local/php/var/run/php-fpm.pid'

 

View the number of php-fpm processes:

$ Ps aux | grep-c php-fpm