On Mon, Mar 21, 2005 at 02:09:51AM +0900, Kirk Haines wrote:
> 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.

ah, you're right, i sometimes forget that the requires are at runtime.

from what eric mentioned earlier, it sounds like fcgi is spawning new
ruby processes instead of forking from a master ruby process.  my fcgi
knowledge is pretty rusty, but if there was a way to do the fork model,
then we could get fcgi rails installs to use less memory.  that said,
since it's fcgi, you're already using a lot less memory, since you're
running a handful of rails fcgi processes fronted by a pool of httpds,
versus the normal cgi model where each httpd loads and runs their own
cgis.  so maybe it's a case of diminishing returns...

> > 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 agree, if you're talking about threaded ruby apps versus the fcgi
model.  i would have said the same is true for ruby/fcgi until you
pointed out that it's not taking much advantage of shared memory.

that said, i wasn't saying that ruby can't fit in the 64MB space, i was
showing that java could fit under eric's 64MB window, since he mentioned
that he thought java wouldn't fit...

> 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.

that's pretty good performance, although it's difficult to assess
without knowing what your app is doing.  this is why it will be great to
get some good, relative benchmarks between the different frameworks out
there.

> 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?

i agree it's hard to do fair benchmarks, but i think it's definitely
doable.  are you thinking just ruby and java?  i would be glad to help
out with this, i have some background in performance testing.

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

ruby totally wins on ease of implementation.  as far as performance
goes, that's much more subjective.  it will be interesting to see the
results of the benchmarks!

doug

-- 
"Contrary to what most people say, the most dangerous animal in the
world is not the lion or the tiger or even the elephant.  It's a shark
riding on an elephant's back, just trampling and eating everything they
see." -- Jack Handey