when i “siege” a particular page on my site, my site just crashed under
a very light load, and cpu usage quickly goes up to 99%. But my other
pages are doing much better with load testing. So my guess initially
was that sql statements with this page is the cause.
However, from "tail -f production.log ", it seems that sql is doing ok
and not taking much time, and “Top” also confirms that mysql takes up
small percentage of CPU, but the 15 dispatch.fcgi use nearly 90% cpu.
It would seem that the problem has to be due to ruby or fcgi
I am quite perplexed. Does anyone have any clue? Much appreciated!
On Feb 23, 2006, at 8:35 AM, Joe B. wrote:
cpu.
Joe-
I think that 15 fcgi's is way too much. For example. I run this site
http://yakimaherald.com with 5 fcgi processes and it serves 80,000+
page views/day. Unless your site is getting huge traffick you are
using way to many fgi’s. For a smaller app like a blog you only need
one or two fcgi. So try setting up just a few fcgi’s and then you can
add more if you need to but running 15 is way too many unless you are
running a huge site and the server is entirely dedicated to just that
site.
Cheers-
-Ezra
On Feb 23, 2006, at 1:03 PM, Ezra Z. wrote:
However, from "tail -f production.log ", it seems that sql is
site http://yakimaherald.com with 5 fcgi processes and it serves
80,000+ page views/day. Unless your site is getting huge traffick
you are using way to many fgi’s. For a smaller app like a blog you
only need one or two fcgi. So try setting up just a few fcgi’s and
then you can add more if you need to but running 15 is way too many
unless you are running a huge site and the server is entirely
dedicated to just that site.
Agreed, you’re probably spending all your time context switching.
www.43people.com. handles about 120k rails requests per day per
machine on four processes per machine (361k total rails requests
yesterday).
www.43things.com handles ~ 370k rails requests per day per machine on
ten processes per machine (1.1 million total rails requests
yesterday). We pushed it up to ten processes because we found it
more performant, originally it was around 6.
The production_log_analyzer gem will show you which pages are the
most beneficial to optimize.
Profiling your pages will show you where those pages are eating up
CPU time. Use the action_profiler gem on your live dataset on a live
machine.
–
Eric H. - [email protected] - http://segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com