Can you give some better stats for your activity? 30k/day comes out to
less
than 1/second if you divide it out, but I’m betting you have a peak
time.
Once you know the peak time, you just need to figure out which server
can
handle it. I’m actually thinking if your peak isn’t all that high (30k
couldn’t peak too high) you could get away with just Mongrel
(http://mongrel.rubyforge.org) and be done with it all.
Last time I looked, Lighttpd only ran on windows under cygwin… and
you DO NOT want to run under cygwin. If I’m wrong and there is a
native Windows version available now, please let me know.
I’m interested to see what people can say about this too with because
I’m currently doing the same kind of choice.
I’ve setup Lighttpd 1.4.10a from Kevin’s site and I’ve tested it with
Mongrel and SCGI rails runner (both from Zed) Lighttpd does the static
side of the site (i.e. anything that start with images, stylesheets,
etc…) and Mongrel or SCGI does the Rails part.
I’ve tested with Jmeter and I get the same result with both setup,
however I dont understand why Jmeters tells me it needs in average 5
seconds to reach my page (with 20 threads running) while the rails
logs tells me it render pages in 0.25 seconds to 0.5 seconds at
worse…
I’m about to test with apache to see if I see a difference
seconds to reach my page (with 20 threads running) while the rails
logs tells me it render pages in 0.25 seconds to 0.5 seconds at
worse…
Jmeter is measuring from the client’s perspective, whereas Rails can
only start and stop its clock when you are actually inside the Rails
code. To give an extreme example, if you were running Rails under CGI,
Rails couldn’t include the time taken to start the CGI process, load
Ruby, and load Rails. It might or might not include the time to load the
application - would have to look at the code to see.
I’m about to test with apache to see if I see a difference
Could you include WEBrick as well? Then post the numbers?
code. To give an extreme example, if you were running Rails under CGI,
Rails couldn’t include the time taken to start the CGI process, load
Ruby, and load Rails. It might or might not include the time to load the
application - would have to look at the code to see.
To give a more relevant example, if you have one FCGI or SCGI process
and the web server receives two concurrent requests, one of the requests
will have to wait until the other has completed. The client will see the
wait time, but Rails won’t be able to measure it.
OK I understand better now…So I guess bringing a new instance of
SCGI process can help getting the pages faster, but it may not.
I’m not sure if it’s quicker to have one SCGI process waiting for the
previous to finish running at full CPU speed than 2 SCGI process
running at the same time but at half of the speed, I’lll investigate
this path too.
Gael
PS: I’m gonna do a complete benchmark of RoR on windows 2003 comparing
different options and posting the result shortly.
OK I understand better now…So I guess bringing a new instance of
SCGI process can help getting the pages faster, but it may not.
I’m not sure if it’s quicker to have one SCGI process waiting for the
previous to finish running at full CPU speed than 2 SCGI process
running at the same time but at half of the speed, I’lll investigate
this path too.
If the SCGI process only uses CPU, then two processes wouldn’t speed
things up - but if it spends some time waiting for I/O, another process
could be using the CPU at that point.
PS: I’m gonna do a complete benchmark of RoR on windows 2003 comparing
different options and posting the result shortly.
Excellent! - thanks
Justin
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.