PHP-CGI vs PHP-FPM on NGINX

Rendus

New Member
Take a closer look at VPSBible's results, their comments on possible issues of accuracy and their overall conclusion.

Personally it's been my experience that php-fpm has been better suited to my particular use, but I've also never explored -cgi.

Think of your current setup like this: You're running a benchmark you don't understand, that's spawning three thousand connection attempts per second, to a mis/poorly-configured server that is doing its best to keep up throwing error messages, to prove that one bad configuration withstands a prison beating better than the other.

It looks like I get up to around 300 hits/second with your example PHP script on my Atom 230 with iSCSI storage, before changing that particular server's config for the task either way. (Edit: Oops - The errors were due to tcp conntrack limits for this kernel, then when I raised that, file handles hitting the php socket file. I'm not about to pick apart this system's config to see how high I can get that number, but I'm up over 500/second before other resource limitations start becoming an issue)

And really, regardless of your opinion on what I'm saying or what tchen is saying, your results just don't stand up to any level of scrutiny. Learn how to use your benchmarking tool, bring your users down to a number your box can hope to handle, fix your configuration and then try again - at least you'd have meaningful data to present at that point. Your current results are useful for planning just how hosed you are under a DDOS, and little more.
 
Last edited by a moderator:

coreyman

Active Member
Verified Provider
Take a closer look at VPSBible's results, their comments on possible issues of accuracy and their overall conclusion.

Personally it's been my experience that php-fpm has been better suited to my particular use, but I've also never explored -cgi.

Think of your current setup like this: You're running a benchmark you don't understand, that's spawning three thousand connection attempts per second, to a mis/poorly-configured server that is doing its best to keep up throwing error messages, to prove that one bad configuration withstands a prison beating better than the other.

It looks like I get up to around 300 hits/second with your example PHP script on my Atom 230 with iSCSI storage, before changing that particular server's config for the task either way.

And really, regardless of your opinion on what I'm saying or what tchen is saying, your results just don't stand up to any level of scrutiny. Learn how to use your benchmarking tool, bring your users down to a number your box can hope to handle, fix your configuration and then try again - at least you'd have meaningful data to present at that point. Your current results are useful for planning just how hosed you are under a DDOS, and little more.
Regardless of how badly I have configured php-fpm and/or php-cgi ..... php-fpm is performing better under the DOS I sent it. Do you think I should bring the number of users down to where I don't have 502's for a better result set?
 

Rendus

New Member
And really, the only *important* question to answer wasn't even sought out: What was your peak concurrency without errors?
Rendus said:
Tsung looks like it's way, way over the top for what you're looking to do with it, although its graph generation is pretty nice - it's a distributed benchmarking platform for throwing thousands of hits per second at a cluster, more than hundreds at some poor Atom.
Rendus said:
You're running a benchmark you don't understand, that's spawning three thousand connection attempts per second, to a mis/poorly-configured server that is doing its best to keep up throwing error messages, to prove that one bad configuration withstands a prison beating better than the other.
Sure, I think that might be worth trying.
 

tchen

New Member
Regardless of how badly I have configured php-fpm and/or php-cgi ..... php-fpm is performing better under the DOS I sent it. Do you think I should bring the number of users down to where I don't have 502's for a better result set?
At the very least run your second test much longer than fastcgi_read_timeout 180;  Double check whether your steady state 200 response rate is lower than FCGI.
 

Mun

Never Forget
If you are using it for a heavy PHP enviornment Apache is still king. I currently push nearly 100 requests a second constantly with Apache all being php, and have little to no issues, where Nginx + php5-fpm left me with a slower performance even with a massive number of php5-fpm pool instances.
 

libro22

Member
If you are using it for a heavy PHP enviornment Apache is still king. I currently push nearly 100 requests a second constantly with Apache all being php, and have little to no issues, where Nginx + php5-fpm left me with a slower performance even with a massive number of php5-fpm pool instances.
I apologize for resurrecting an old thread but what were you using mod_php for this?
 
Top