On Sat, Mar 19, 2005 at 07:29:38AM +0900, Eric Hodel wrote:
> 
> 43 Things averages 46661 KB/Rails process (we peak at 200,000 
> pageviews/day running 40 processes FastCGI across 2 servers).  Most of 
> the time load hovers around 0.10 to 0.20 (we have dual 3GHz Xeons with 
> 2GB RAM), but peaks at about 0.50.

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.

> I was under the impression that Java takes up a much larger memory
> footprint, but have never actually used it so I can't say how much
> memory it takes.  I have no idea how much CPU an equivalent Java site
> would use.
> 
> Please provide some relevant data about how much memory/CPU a Java site 
> would need to have equivalent performance.
> 
> People have just managed to fit Rails into 64MB virtual servers.  I 
> doubt you could do the same with a Java app.

i can tell you that 64MB is quite doable with most j2ee containers, and
in fact i would argue it's easier to constrain memory usage with java
web apps than it is with ruby rails apps.  while it's not as hungry as
perl, ruby is pretty liberal with memory usage.

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

as far as container memory usage goes, you can also use jvm switches to
set min/max limits for jvm memory usage, so you can force java to stay
within a given memory usage range, while the same is not true for ruby.
you still have to make sure you don't create too many request threads
and get an OutOfMemoryError, but it is a cleaner failure mode versus
having the OS just kill your process without warning when you reach your
limit.

re: cpu usage, it would be interesting to do some benchmark comparisons.
the major containers out there are pretty mature and have a lot of
optimizations to help with GC; they reuse per-request objects, push
declarations to the widest scope possible, avoid destruction, etc.
servlets have deeper call chains when dealing with requests than webrick
does, but when you factor in the near-C speed of modern jvms with the
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.

of course, i don't think that being the market leader in speed or memory
usage is rails's goal.  it's a lightweight and agile web app framework
that lets you get things running 10x faster than any other framework out
there.  i think it's awesome, and the more i use rails, the more i like
it.

i just wanted to give some data points showing that java isn't the
memory/cpu hog it is sometimes made out to be.  i think rails is great
for rapid development and prototyping, and for running small to moderate
request loads, but if i'm deploying the app for enterprise request
rates, i'm probably going to port it to java for the final deployment.
hardware is cheap, but not that cheap.  :-)

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