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);
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.
> 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...
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.
On 6月22日, 下午4时00分, mike <mike...@gmail.com> wrote:
> > 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...
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.
> 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.
> On 6月22日, 下午4时00分, mike <mike...@gmail.com> wrote: > > On 6/21/08, Nanu <nanu...@gmail.com> wrote:
> > > 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...
On Mon, Jun 23, 2008 at 1:21 AM, mike <mike...@gmail.com> wrote: > 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.
>> 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.
>> On 6月22日, 下午4时00分, mike <mike...@gmail.com> wrote: >> > On 6/21/08, Nanu <nanu...@gmail.com> wrote:
>> > > 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...
|
