overhead of WEBrick served http?

[Martin Pirker]

Hi...

I'm running here a servlet off WEBrick.
Each request is rendered in xx-xxx request/s time by my code
(measured exit time-entry time of servlet)

So res.body is filled with xx-xxx kb html, what I'm wondering
a) how to best measure the overhead caused by doing also the
actual socket stuff/http transport in Ruby (=in WEBrick)
= the real requests/s
b) probably someone already compared this to other http server
interfaces (fastCGI?), if I do only the request rendering
in Ruby and http stuff by pure C server, would this be
much faster?

Martin

 

[Andreas Schwarz]

I'm running here a servlet off WEBrick.
Each request is rendered in xx-xxx request/s time by my code
(measured exit time-entry time of servlet)

So res.body is filled with xx-xxx kb html, what I'm wondering
a) how to best measure the overhead caused by doing also the
actual socket stuff/http transport in Ruby (=in WEBrick)
= the real requests/s

Try ApacheBench (ab).

b) probably someone already compared this to other http server
interfaces (fastCGI?), if I do only the request rendering
in Ruby and http stuff by pure C server, would this be
much faster?

FastCGI is faster (expecially when you use the FastCGI C extension for
Ruby), not only because of the less amount of work done in ruby, but
also because you can use multiple ruby processes in parallel instead of
Ruby threads.

 

[Kirk Haines]

On Mon, 11 Oct 2004 21:14:41 +0900, Martin Pirker wrote

b) probably someone already compared this to other http server
interfaces (fastCGI?), if I do only the request rendering
in Ruby and http stuff by pure C server, would this be
much faster?

I can tell you what I have found with IOWA. Using it via fcgi and mod_ruby
delivers very close to identical performance. Using it under Webrick
delivers about 2/3rds the performance of using it via Apache. IMHO those
are pretty surprisingly good numbers.

Page load benchmarks are meaningless without knowing what the page being
loaded/rendered looks like, so take this with a grain of salt, but what this
means is that on old, non-dedicated hardware (800 Mhz PIII that also runs a
complete KDE desktop environment), for a typical web page that is a few k in
length, with some simple IOWA work mixed in, benchmarks run in the low 30s
of pages/second via Apache with either mod_ruby of fcgi. With Webrick, the
same pages return in the low 20s/second.

I'm not sure about running Webrick in a production environment, but I have,
overall, been impressed by its performance.


Kirk Haines

 

[Martin Pirker]

Using it under Webrick
delivers about 2/3rds the performance of using it via Apache. IMHO those
are pretty surprisingly good numbers.

these sound very promising, thanks!

I'm not sure about running Webrick in a production environment, but I have,
overall, been impressed by its performance.

I went for the "all in Ruby" approach because the payoff in instant
portability - Linux, Windows, Solaris(?) - IMHO lets one forget the
halved(?) performance.

req.query[..] stuff from WEBrick is currently pretty hardwired in, so
FastCGI would be some work, but speedwise there's no need (yet?) and I
guess I'm just loosing lotsa in

table {
whatever.collect......
tr{ td{..} << td{..} << ... }
end
}

like constructs :-/


Martin