Doug Beaver wrote:
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.
Yep yep. Meaningful benchmarks can be hard.
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.
I'm thinking primarily to look at Ruby approaches, but with rolling in a
comparison with some common Java standard approach, and perhaps a Perl
and/or Python standard approach, as well.
Kirk Haines
hi lothar,
i didn't include enough details before...
if you had a way to register what modules your app depended on, then you
could make sure to load those in the master ruby process that the fcgi
children would be forked from. copy-on-write would then make the kids
use less memory than if each fcgi was spawned on the fly and loaded the
modules on their own. that would be happening at a lower level than
ruby's GC, so i figured that would work.
but it sounds like you're saying that even if the code did that, the
first GC run in the child would walk the list of data/code nodes and
twiddle them in one way or another, causing copy-on-write to happen for
all nodes, and negating any benefit from being forked from a master
parent process. did i read you correctly? if so, that's interesting, i
never expected that...
doug
···
On Mon, Mar 21, 2005 at 08:26:28AM +0900, Lothar Scholz wrote:
Hello Doug,
>> 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...
How should a forking modell help with memory here ?
The first time you get a GC run (and that happens very often) ruby
walks the whole memory and sets flags in data and code (ruby code
nodes are also collected by the GC). At this time the MMU of the CPU
will do a copy on write. So only if you have a lot of large strings or
read only arrays then you will win something. But i doubt that this is
the usual case.
--
"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
Hello Doug,
if you had a way to register what modules your app depended on, then you
could make sure to load those in the master ruby process that the fcgi
children would be forked from. copy-on-write would then make the kids
use less memory than if each fcgi was spawned on the fly and loaded the
modules on their own. that would be happening at a lower level than
ruby's GC, so i figured that would work.
but it sounds like you're saying that even if the code did that, the
first GC run in the child would walk the list of data/code nodes and
twiddle them in one way or another, causing copy-on-write to happen for
all nodes, and negating any benefit from being forked from a master
parent process. did i read you correctly? if so, that's interesting, i
never expected that...
Yes seems that you got my point. A lot of the ruby data part will
always be copied with the first GC run. I don't know how much memory
is used by the interpreter and the *.so extensions, but i doubt that it
is not the huge part. Each data member has a flag as part of the
allocated memory that will be flagged in the mark phase.
But memory consumption is like performance profiling: not very
intuitive, so someone with a lot of time should measure the things
a little bit more. But i pay him a few beer's on the next Ruby Conf
if i'm wrong with my assumption.
···
doug
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's