I was told by someone that tried to write a daemon process in Ruby to
serve treaming audio files to multiple clients that it uses alot of
memory which made the web server usage too high. Too high meaning the
amount allocatable memory from a web service where you don’t own the
web server and pay based on your usage etc. I was told threads in Ruby
are not native threads and that since Ruby doesn’t have a virtual
machine that this was also part of it. I am just trying to find out
more, and if what I said makes sense to other people here. Also, would
using Perl be different if this was the case ?
On Wed, 3 Jan 2007, [email protected] wrote:
I was told by someone that tried to write a daemon process in Ruby to
serve treaming audio files to multiple clients that it uses alot of
memory which made the web server usage too high. Too high meaning the
amount allocatable memory from a web service where you don’t own the
web server and pay based on your usage etc. I was told threads in Ruby
are not native threads and that since Ruby doesn’t have a virtual
machine that this was also part of it. I am just trying to find out
more, and if what I said makes sense to other people here. Also, would
using Perl be different if this was the case ?
There are WAY too many variables in the above information.
You can run a Ruby daemon in a few MB of RAM, depending on what it is
doing.
If the goal is to minimize RAM usage, one is better off using something
other Ruby or Perl, though. C might be good. Still, one can pack a lot
of functionality in a fairly small (relative to the RAM in a modern
system) memory footprint.
Kirk H.
[email protected] wrote:
using Perl be different if this was the case ?
There are WAY too many variables in the above information.
You can run a Ruby daemon in a few MB of RAM, depending on what it is
doing.If the goal is to minimize RAM usage, one is better off using something
other Ruby or Perl, though. C might be good. Still, one can pack a lot
of functionality in a fairly small (relative to the RAM in a modern
system) memory footprint.
Usually if a daemon process is holding onto memory it isn’t the
language’s fault. Usually it is from the application on deferencing and
finalizing variables and such. If you can rule that out, then the
libraries used are next suspect, then (and really only then) should
the finger be pointed at the language.
If your app involves audio streaming there is a good bet it is
dynamically allocating a rather large memory buffer in order to keep
the bitstream rate high. That might be configurable depending on the
app, which is where I’d suggest focusing your attention rather than the
language.