webrick in production use?

[Navindra Umanee]

Hi,

Is anyone here using WEBrick on a production site? Do any of the
famous Rails sites out there use it?

I've heard that FastCGI is probably the best option for deploying a
production Ruby-based website. Unfortunately, I was betting on using
WEBrick for my backend (Apache would still be in front), and it would
be quite disappointing to find that it's not up to the task.

So, any anecdotes of successful and significant WEBrick deployments
out there?

Thanks,
Navin.

 

[David Heinemeier Hansson]

Is anyone here using WEBrick on a production site? Do any of the

famous Rails sites out there use it?

instiki.org and wiki.rubyonrails.com both run WEBrick and are doing
fine.

I've heard that FastCGI is probably the best option for deploying a
production Ruby-based website. Unfortunately, I was betting on using
WEBrick for my backend (Apache would still be in front), and it would
be quite disappointing to find that it's not up to the task.

So, any anecdotes of successful and significant WEBrick deployments
out there?

There's nothing preventing you from doing that. If WEBrick is fast
enough for your site, then by all means go for it. But if its not fast
enough, you'll need to get on FastCGI.

I'm not sure why you wouldn't want to use FastCGI if you're using
Apache anyway? Then you wouldn't have to play proxy either.

 

[khaines]

On Tue, 8 Mar 2005 13:00:06 +0900, Navindra Umanee wrote

I've heard that FastCGI is probably the best option for deploying a
production Ruby-based website. Unfortunately, I was betting on using
WEBrick for my backend (Apache would still be in front), and it would
be quite disappointing to find that it's not up to the task.

Depends on what you mean by "up to the task". It will deliver nowhere near
the performance of a C web server like Lighttpd or Apache when serving static
files.

However, it can perform quite adequately for dynamic content, depending on how
you are generating that dynamic content.

I have no problem getting 40-60 requests per second from it for real world web
applications and dynamic content on relatively modest hardware, and even on
older hardware (800 Mhz PIII running Gentoo Linux), I can easily get in the
low 20s on requests per second.

It all depends on the performance that you need and the hardware that you have.

Doing some performance testing on the cutting edge version of my IOWA
framework, and using lighttpd plus FastCGI, I'm getting around 130 requests
per second for my test application, which is a real app, and around 220/second
for a simple "Hello World" sort of page in my initial tests on a single CPU
AMD2600 machine running RedHat Enterprise Linux 3.0. Webrick performance on
the same machine is, roughly, 1/2 to 1/3rd of that, and the FCGI approach has
the advantage of scaling just by adding more machines.

So, it really depends on what your production needs are. For modest usage,
especially if there is a lot of dynamic content and not a lot of static
content, I see no reason why one could not use webrick in production.

For high performance, though, FCGI is hard to beat.


Kirk Haines

 

[Navindra Umanee]

There's nothing preventing you from doing that. If WEBrick is fast
enough for your site, then by all means go for it. But if its not fast
enough, you'll need to get on FastCGI.

Well the site is dot.kde.org, so I need it to be able to withstand a
Slashdotting.

I'm not sure why you wouldn't want to use FastCGI if you're using
Apache anyway? Then you wouldn't have to play proxy either.

WEBrick is serving as the point of entry for the backend.

Thanks,
Navin.

 

[khaines]

There's nothing preventing you from doing that. If WEBrick is fast
enough for your site, then by all means go for it. But if its not fast
enough, you'll need to get on FastCGI.

Well the site is dot.kde.org, so I need it to be able to withstand a
Slashdotting.[/QUOTE]

You _probably_ don't want to use Webrick, then. I count 8 static images on
that page. If they are served with webrick, too, your time to service a
complete page request will increase quite a bit, and you will definitely not
be happy when you are slashdotted.


Kirk Haines

 

[Navindra Umanee]

You _probably_ don't want to use Webrick, then. I count 8 static images on
that page. If they are served with webrick, too, your time to service a
complete page request will increase quite a bit, and you will definitely not
be happy when you are slashdotted.

The static images are not a problem, they can be served by an external
server like they are now.

It's just that using WEBrick makes things nice and convenient
implementation-wise... I hope it'll work out in practice.

Cheers,
Navin.

 

[ES]

The static images are not a problem, they can be served by an external
server like they are now.

It's just that using WEBrick makes things nice and convenient
implementation-wise... I hope it'll work out in practice.

Well, you could try submitting 'dot.kde.org Using Neat Ruby Library As
Its Webserver' to Slashdot

Cheers,
Navin.

E

 

[Navindra Umanee]

Well, you could try submitting 'dot.kde.org Using Neat Ruby Library As
Its Webserver' to Slashdot

Yeah, just in case there is any confusion, dot.kde.org is running Zope
now not WEBrick...

Cheers,
Navin.

 

[Mark Firestone]

...looking for some good, really retro computer equipment, at various
angles, for this project (which is off topic... and may offend sensitive
Scotts Gardsmen...)

http://www.ebriusology.info

Basically, it's so Chrispin Glover, the Mystic Mollusk can have an
interface device. Photoshop, here I come...

 

[Bill Guindon]

...looking for some good, really retro computer equipment, at various
angles, for this project (which is off topic... and may offend sensitive
Scotts Gardsmen...)

http://www.ebriusology.info

Basically, it's so Chrispin Glover, the Mystic Mollusk can have an
interface device. Photoshop, here I come...

This will find ya quite a few:
http://www.google.com/search?&q=computer+museum

Including my 1st machine (conveniently at an odd angle):
http://www.obsoletecomputermuseum.org/trs80iii/