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...
> 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.
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)
> "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.