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.