[Rails] Webrick in production?

[Ben Munat]

Thanks for the explanation Zed. I see that the threading issue is with Rails and not 
Mongrel and there's not much you can do about that. That's still frustrating, but well, 
I'll just have to deal... or look into other Ruby web frameworks.

I wish there was a bit more energy behind the Nitro effort... more docs would be nice. And 
actually, even with more docs I just don't see them having the same level of 
crunchy-goodness as Rails any time soon.

Oh, and for the record, I may have misrepresented what Eric said... he said "I don't see 
what benefit Mongrel would give me" but really he was simply talking about speed at 
serving images... nothing involving thread issues, ease of app deployment, running 
multiple apps, or any other points that I would consider pertinent to the servlet 
container topic.

b

Zed Shaw wrote:
> 
> 
> On 3/4/06 1:04 PM, "Ben Munat" <bent at munat.com> wrote:
> 
> 
>>Zed Shaw wrote:
> 
> 
>>>Yes, Mongrel has to use a "grand mutex" around the Dispatcher.dispatch in
>>>order to prevent Rails from going crazy.  Rails just isn't thread safe.
>>>
>>>One thing you can do in both Mongrel (and WEBrick) is if there's a
>>>particular little part of your Rails application that needs to run very
>>>fast, then write a handler that runs right inside Mongrel.  This then moves
>>>the processing out reducing the overhead and giving you full threaded
>>>operation (which you have to be careful of yourself).
>>
>>Wow. This just took the wind out of my sails.
>>
>>So, I should pretty much forget ever seeing a servlet container for rails?
>>Sorry Zed, but 
>>this pretty much brings me around to Eric's point of view: why bother creating
>>Mongrel at all?
>>
> 
> 
> Well, first off, this threading issue is Rail's problem, not Mongrel's.
> Nitro and Camping don't have this problem AFAIK.
> 
> Second, Mongrel already is a "servlet container" for Ruby web applications.
> It has all the things you need to write your own web applications directly.
> In fact, that's why it supports Nitro and Camping.  The Nitro and Camping
> folks just grabbed Mongrel and wrote their own handlers to support their web
> framework.
> 
> Take a look at the docs for:
> 
> http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpHandler.html
> http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html
> http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpResponse.html
> http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpServer.html
> 
> See?  Very much like your average "servlet container".  The only real thing
> missing is the ability to load apps from gems or a directory (which is in
> the works as we speak).
> 
> 
> Now, as for why bother writing Mongrel (not sure if Eric really said that):
> 
> Why bother writing Ruby?  I mean, didn't we already have C?
> 
> For people who want the current best practice I say go with FastCGI.
> FastCGI however is a royal pain in the ass to manage (YMMV).  The
> alternative way is to serve your applications directly using WEBrick.  This
> gives you the advantage of the flexible simplicity of HTTP (think load
> balancers), but WEBrick is incredibly slow.
> 
> Mongrel tries to be right in this niche:  The speed of FastCGI with the
> simplicity of WEBrick for hosting.  For many people the fact that Mongrel
> supports win32 just as well as POSIX systems is a big win.  I've also heard
> other people like it for development since it's quicker than WEBrick but
> just as easy to start.  Other folks are using it to serve minor intranet
> sites directly since they don't need to service a huge load but don't want
> things slow for the few people they have.
> 
> Finally, I've been working on a best practice document:
> 
> http://mongrel.rubyforge.org/docs/lighttpd.html
> 
> That will tell folks how to hook up a lighttpd+mongrel+memcache setup that
> should be competitive with the current crop of FastCGI configurations.
> 
> Anyway, how else would I get to play with a Ragel HTTP parser and ternary
> search tries?  :-)
> 
> 
> Zed A. Shaw
> http://www.zedshaw.com/
> 
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails