Doug Beaver wrote:

> i'm surprised you're using so much memory.  is the 46MB number just
> rss, or rss+shared?  i would expect your rss-per-process to be 1-10MB,
> with >10MB being indicative of leaks, unless you're doing lots of
> per-process caching, which doesn't make a lot of sense from a locality
> perspective anyways.

No, you have it backwards.  With Ruby, the shared portion between processes
ends up being quite small.  The Ruby interpreter itself is pretty
lightweight, and that is the only code that is shared.  All of the code
that is loaded afterwards is duplicated per process.  So the RSS of each
process ends up being within a few mb of the total RAM usage,
approximately.

> i've had containers with 20+ server threads use 25MB, and i bet you
> could tune them even smaller than that if you stripped out non-essential
> features.  it does depend on which container you use, though.  with
> containers, you get a fixed cost for the container itself (10-20MB), and
> then a per-thread overhead of 100-200KB.  just ruby itself on OS X takes
> 1.3MB rss per process, so you can see how much more memory ruby is
> using for each handler...

It depends on the code being benchmarked, but that sort of memory usage is
no problem at all with Ruby.

I just ran a few quick benchmarks with an app I have going into production
soon (IOWA app, unlreleased version of IOWA).  On startup, it's total RAM
usage is about 15.0Mb, of which about 12.5Mb is RSS.

I can run it with 200 concurrent request threads and 200 cached sessions
with a total RAM usage of less than 25Mb, consistently.  The RAM usage
doesn't grow.  No leaks.  This is on an AMD2600 based Linux box with a 2.4
kernel,and with that single process, for this particular app, with even
1000 concurrent (green) threads, it has a throughput of about 105
requests/second at about 9k of dynamically generated HTML per request.  If
I reduce the concurrency to 1, on one process I can get 140
requests/second, and if I run 2 processes, 150 requests/second on this app.
Ruby acquits itself quite adequately regarding performance, as far as I am
concerned.

> relatively mature containers out there, i would be surprised if rails
> could handle requests with less cpu time expended per-request or handle
> more aggregate requests per second than a servlet app.

The trick with this sort of comparison is in comparing apples to apples.  I
have long been interested in writing an article or three that compares
implementation details and then performance of some task or tasks in Ruby
and non-Ruby frameworks.  It's not an easy task, though.  The choice of
fair benchmarks, and then the task of getting good, equivalent
implementations of the task(s) under the frameworks to be compared is
fraught with challenges.  Anyone want to help?

My hunch is that Ruby frameworks will acquit themselves quite well on both
the ease of implementation AND performance fronts.


Kirk Haines