Overhead of WEBrick served http?

ruby-talk
1

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

2

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

···

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?

3

Martin Pirker wrote:

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.

···

--
http://www.mikrocontroller.net - Das Mikrocontroller-Forum

4

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

···

Kirk Haines <khaines@enigo.com> wrote: