[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

WEBrick and mod_ruby performance

quixoticsycophant

9/3/2003 10:29:00 PM

I've been scoping out ruby for an upcoming server project.

For my purpose, performance will be a factor because the server will
be slending data in real-time much like a multipayer game server such
as Quake (as opposed to waiting for user input). Quake is an extreme
example, though -- it wouldn't be nearly that demanding.

I am very impressed with WEBrick, and this would be my primary choice
were it not for performance concerns.

How does WEBrick scale? Looking through the code, it appears that new
requests are handled by a ruby Thread -- as opposed to a native thread
or a fork. What happens with 40 threads, all transferring data and
doing stuff, all being handled by a single ruby process setjmp-ing and
longjmp-ing around? I'm guessing performance would be poor.

Next option is mod_ruby. Now I don't even understand how mod_ruby
works with Apache 2.0 since the ruby interpreter isn't thread-safe.
So that's all a mystery to me. Apache 1.3 + mod_perl is probably
well-tested and perhaps the most appropriate choice.

Are the above assumptions correct, and are there other options? One
more option which comes to mind is to simply write a forking ruby
server from scratch. This would mean more development time, but how
much more I'm not sure.
14 Answers

ahoward

9/3/2003 11:30:00 PM

0

Dmitry Borodaenko

9/4/2003 2:48:00 PM

0

On Thu, Sep 04, 2003 at 09:24:07AM +0900, ahoward wrote:
> you should definitely check out fastcgi and the ruby fastcgi binding. it''s
> AWESOMELY fast:
>
> ~ > ab http://eli/env.cgi | grep ''per second''
> Requests per second: 4.04 [#/sec] (mean)

What are you comparing it against: plain cgi, mod_ruby, or webrick?

> ~ > ab http://eli/env.fcgi | grep ''per second''
> Requests per second: 557.10 [#/sec] (mean)

--
Dmitry Borodaenko

quixoticsycophant

9/4/2003 5:47:00 PM

0

Dmitry Borodaenko <d.borodaenko@sam-solutions.net> wrote in message news:<20030904144727.GB9114@sam-solutions.net>...
> On Thu, Sep 04, 2003 at 09:24:07AM +0900, ahoward wrote:
> > you should definitely check out fastcgi and the ruby fastcgi binding. it''s
> > AWESOMELY fast:
> >
> > ~ > ab http://eli/env.cgi | grep ''per second''
> > Requests per second: 4.04 [#/sec] (mean)
>
> What are you comparing it against: plain cgi, mod_ruby, or webrick?
>
> > ~ > ab http://eli/env.fcgi | grep ''per second''
> > Requests per second: 557.10 [#/sec] (mean)

ahoward''s post was unclear to me as well.

The performance of fastcgi would be essentially the same as
for mod_ruby, would it not?

ahoward

9/4/2003 6:15:00 PM

0

kwatch

9/10/2003 1:33:00 PM

0

You can try ''esehttpd''
http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/...

It is very fast as HTTP server and CGI engine,
twice (or more) as fast as Apache + mod_ruby.

--
regards
kwatch

quixoticsycophant@yahoo.com (Jeff Mitchell) wrote in message news:<a45fa95e.0309031429.549b72a3@posting.google.com>...
> I''ve been scoping out ruby for an upcoming server project.
>
> For my purpose, performance will be a factor because the server will
> be slending data in real-time much like a multipayer game server such
> as Quake (as opposed to waiting for user input). Quake is an extreme
> example, though -- it wouldn''t be nearly that demanding.
>
> I am very impressed with WEBrick, and this would be my primary choice
> were it not for performance concerns.
>
> How does WEBrick scale? Looking through the code, it appears that new
> requests are handled by a ruby Thread -- as opposed to a native thread
> or a fork. What happens with 40 threads, all transferring data and
> doing stuff, all being handled by a single ruby process setjmp-ing and
> longjmp-ing around? I''m guessing performance would be poor.
>
> Next option is mod_ruby. Now I don''t even understand how mod_ruby
> works with Apache 2.0 since the ruby interpreter isn''t thread-safe.
> So that''s all a mystery to me. Apache 1.3 + mod_perl is probably
> well-tested and perhaps the most appropriate choice.
>
> Are the above assumptions correct, and are there other options? One
> more option which comes to mind is to simply write a forking ruby
> server from scratch. This would mean more development time, but how
> much more I''m not sure.

mgarriss

9/10/2003 2:56:00 PM

0

kwatch wrote:

>You can try ''esehttpd''
>http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/...
>
>It is very fast as HTTP server and CGI engine,
>twice (or more) as fast as Apache + mod_ruby.
>
>

Why am I just now hearing about this?! Ugh. $40 on an apache book, oh
well, now I can put apache on my resume and forget about it. ;) Thanks
for the link.

Michael

ahoward

9/10/2003 4:43:00 PM

0

mgarriss

9/10/2003 5:48:00 PM

0

ahoward wrote:

>On Wed, 10 Sep 2003, Michael Garriss wrote:
>
>
>
>>kwatch wrote:
>>
>>
>>
>>>You can try ''esehttpd''
>>>http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/...
>>>
>>>It is very fast as HTTP server and CGI engine,
>>>twice (or more) as fast as Apache + mod_ruby.
>>>
>>>
>>>
>>>
>>Why am I just now hearing about this?! Ugh. $40 on an apache book, oh
>>well, now I can put apache on my resume and forget about it. ;) Thanks
>>for the link.
>>
>>
>
>this looks o.k. - but the ENTIRE webserver is blocked when running ONE cgi
>program. eg. it''s not a forking server. if you want speed, ease of
>development, safety, and _scalability_ i''d check out using apache/fastcgi/ruby
>- might want to hang on to that apache book. ;-)
>
>
>

Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well
that book is still right next to my monitor, close call. ;) I wonder
if I can abstract away the server somehow so I can port my app to any
server?

I''m curious about using fastcgi with apache. Right now I''m not using
cgi.rb at all and just using the Apache::Request class (using my own
cookie class, etc). Are there speed benefits of using fastcgi over this
approach? If so can you give me a push in the fastcgi direction (a link
or whatever)?

TIA
Michael

Aria Stewart

9/10/2003 6:03:00 PM

0

> Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well
> that book is still right next to my monitor, close call. ;) I wonder
> if I can abstract away the server somehow so I can port my app to any
> server?
>
> I''m curious about using fastcgi with apache. Right now I''m not using
> cgi.rb at all and just using the Apache::Request class (using my own
> cookie class, etc). Are there speed benefits of using fastcgi over this
> approach? If so can you give me a push in the fastcgi direction (a link
> or whatever)?

cgi.rb is that abstraction. It handles apache requests, cgi and
fast_cgi all in the same code. An app written with fast_cgi in mind
using the CGI module will work in all three environs.

Ari

mgarriss

9/10/2003 6:43:00 PM

0

Aredridel wrote:

>>Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well
>>that book is still right next to my monitor, close call. ;) I wonder
>>if I can abstract away the server somehow so I can port my app to any
>>server?
>>
>>I''m curious about using fastcgi with apache. Right now I''m not using
>>cgi.rb at all and just using the Apache::Request class (using my own
>>cookie class, etc). Are there speed benefits of using fastcgi over this
>>approach? If so can you give me a push in the fastcgi direction (a link
>>or whatever)?
>>
>>
>
>cgi.rb is that abstraction. It handles apache requests, cgi and
>fast_cgi all in the same code. An app written with fast_cgi in mind
>using the CGI module will work in all three environs.
>
>

Excuse my noobness on this. So when I do a look on RAA I find
FastCGI-0.5 by Eli Green and also I find that there is a mod_fastcgi
for apache. Which are we talking about? Or do I have to have
FastCGI-0.5 sit on top of mod_fastcgi?

Michael