PHP-FPM on highload tips
Nanu
following tips may be useful to you : )
1. Compile PHP's modules as less as possible, the simple the best
(fast);
2. Increas PHP FastCGI child number to 100 and even more. Sometime,
200 is OK! ( On 4GB memory server);
3. Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;
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
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.
mike
>
> 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...
Nanu
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.
On 6月22日, 下午4时00分, mike <mike...@gmail.com> wrote:
mike
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.
