PHP-FPM高负载技巧 (PHP-FPM on highload tips)

When you running a highload website with PHP-FPM via FastCGI, the following tips may be useful to you : )

您使用PHP-FPM运营FastCGI的高负载网站，这些技巧也许对您有用：）

 

1. Compile PHP’s modules as less as possible, the simple the best (fast);

 

1.尽量少安装PHP模块，最简单是最好（快）的

 

2. Increas PHP FastCGI child number to 100 and even more. Sometime, 200 is OK! ( On 4GB memory server);

 

2.把您的PHP FastCGI子进程数调到100或以上，在4G内存的服务器上200就可以

 

3. Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;

 

3.使用socket连接FastCGi，在linux把信息放在 /dev/shm

 

4. Increase Linux “max open files”, using the following command (must be root):

    # echo ‘ulimit -HSn 65536′ >> /etc/profile
    # echo ‘ulimit -HSn 65536 >> /etc/rc.local
    # source /etc/profile 

 

4.调高linux的max open files，可以使用这些命令(必须是root帐号)

  echo ‘ulimit -HSn 65536′ >> /etc/profile 
  echo ‘ulimit -HSn 65536 >> /etc/rc.local
  source /etc/profile 

 

5. Increase PHP-FPM open file description rlimit:
    # vi /path/to/php-fpm.conf
    Find “<value name=”rlimit_files”>1024</value>”
    Change 1024 to 4096 or higher number.
    Restart PHP-FPM.

 

6. Using PHP code accelerator, e.g eAccelerator, XCache. And set “cache_dir” to /dev/shm on Linux.

 

6.使用php代码加速器，例如 eAccelerator, XCache.在linux平台上可以把`cache_dir`指向 /dev/shm

 

re----------------

 

> When you running a highload website with PHP-FPM via FastCGI, the 
> following tips may be useful to you : ) 

> 1. Compile PHP's modules as less as possible, the simple the best 
> (fast); 

Compiling more into the core of PHP means a larger footprint each 
instance created. Sometimes it makes sense to have modules for those 
modules that don't need to be used very often... 

 

> 2. Increas PHP FastCGI child number to 100 and even more. Sometime, 
> 200 is OK! ( On 4GB memory server); 

I'd say it depends on your load. PHP-FPM will soon adapt to the load 
anyway, so this should be moot. 

 

> 3. Using SOCKET PHP FastCGI, and put into /dev/shm on Linux; 

Many people have had issues with socket-based PHP/FastCGI. In fact, 
someone just had an issue on nginx mailing list (or was it IRC?) the 
other day - he changed to using TCP over localhost and his issues went 
away. I have read over the years many issues about using sockets 
(possibly related to heavy MySQL traffic too, I forget) 

 

> 6. Using PHP code accelerator, e.g eAccelerator, XCache. And set 
> "cache_dir" to /dev/shm on Linux. 

 

don't forget APC :) imho eAccelerator hasn't kept up with the times, 
it used to be Turck MMCache, then it slowly died out, renamed to 
eAccelerator, but didn't seem to have as much support/was buggier than 
APC. I've also used xcache, I saw no noticable difference though, and 
APC has the file upload hooks (although I am not using them) - I 
figure APC is probably the best as it's maintained by PHP core 
developers and if I recall a bytecode cache will be built in to PHP6 
anyway and it's probably based off APC if so... 

 

re-------------

Long time ago, when I use APC I got the problem that if there are two 
PHP scripts with the same filename ( in different directory ), the APC 
can not cache the two scripts with the same filename correctly. I 
don't know this problem fixed or not. And eAccelerator keep up all the 
time, but very very slow :), as the 0.9.5.3 release last month. 

I tested XCache, APC and eAccelerator on many China highload websites, 
the performance is eAccelerator > APC > XCache, those websites have a 
PageView of more than 3,000,000 per day, even more than 5,000,000. 

 

 

re-------

Interesting. I've never benchmarked my stuff. Perhaps you should kick 
this over to the APC team and make them feel bad about it. They're 
core PHP devs, why is someone else's bytecache faster? :) 

I've got probably ~ 3 million PHP-based requests per day spread over 3 
webservers. Total number of FastCGI engines is only something like 70 
(I have different pools for each of my clients) and it seems 
sufficient. I am excited when PHP-FPM handles the load for me so I am 
not wasting resources and if I am getting close to limits it will 
launch more engines for me... but throwing a million engines at 
something, I guess if you have a dedicated machine + the RAM for it, 
go for it :) 

Also - if you do authenticated downloads or anything requiring PHP to 
open a file and send it to the browser (which keeps that engine busy 
for a long time) look at offloading it (X-Accel-Redirect in nginx 
[nginx is my webserver of choice now), X-Lighttpd-Sendfile [I believe] 
in Lighttpd, and Apache has module(s) too) - that way PHP can stop 
having to process spoonfeeding the files to the end user and that work 
is offloaded to the webserver.