[Mongrel] Simple Mongrel performance question

Zed Shaw zedshaw at zedshaw.com
Tue Sep 5 19:12:22 EDT 2006


On Tue, 2006-09-05 at 08:46 -0600, Kirk Haines wrote:
> Zed,
> 
> Do you have a feeling for how Mongrel's speed has changed since you
> started out?  Just Mongrel with a plain static file; not burdened with
> having to go through Rails.
> 
> You initial numbers were substantially faster than webrick.  Now that
> there is a lot more stuff in Mongrel, are they still substantially
> faster in your benchmarks?
> 

Yep, actually I was just running a few little tests right now.  Take a
look:

> summary(perfd)
     mngrl          sside          wbrick
 Min.   :1426   Min.   :1777   Min.   :364.3
 1st Qu.:1492   1st Qu.:3108   1st Qu.:382.4
 Median :1493   Median :3164   Median :384.2
 Mean   :1488   Mean   :3020   Mean   :383.4
 3rd Qu.:1494   3rd Qu.:3192   3rd Qu.:387.9
 Max.   :1509   Max.   :3284   Max.   :390.6

> sd(perfd)
     mngrl      sside     wbrick
 22.618736 446.010569   7.422556

Which when you break out the standard deviations (2*sd) you get:

Mongrel:    1444 to 1532
ServerSide: 2128 to 3912
Webrick:    369  to 397

(That's theoretical performance, I'm thinking serverside isn't really
that erratic).

You can also get all of the data I used, my RData and Rhistory, as well
as graphs of the two servers performance as line and boxplots at:

http://mongrel.rubyforge.org/perftest/

I'd say ServerSide is kicking some serious ass, but it's got a long way
to go before it can run a rails app.  It also has these problems
currently:

1) Doesn't use a parser but rather a couple regular expressions to parse
HTTP.  This will most likely blossom into a giant set of regular
expressions (which is a lot like a parser anyway), and won't have the
security advantages that a parser has.
2) It loads the whole file in ram.  I tried serving a ISO image and that
process used 660M of ram.  Mongrel streams files so it serves larger
files slower, but will actually serve them without running out.
3) It seems to choke when you hit it with a lot of requests, mostly
because it doesn't defend against all the various weird exceptions ruby
throws when things start to go really wrong.
4) It doesn't support a lot of the gear needed to run web frameworks
like handler chains, objects for processing request and response data
(he rejects it directly), and a CGI wrapper.
5) Creates a monitoring process to track the other processes.  Ruby's
very terrible at this, whereas other tools like monit and daemontools
are fantastic at this (which is why we went with a mongrel_cluster kind
of thing).  This also means it won't support win32 most likely.
6) Doesn't seem to perform too consistently, but it's fast enough that
most people wouldn't care.

It's still pretty impressive for a first run.  I'd be curious to see if
some kind of mongrel+severside alliance could be had, but I suspect the
author has his eye on the "fastest web server" prize.

-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.



More information about the Mongrel-users mailing list