[Mongrel] Deployement options

Jeremy Kemper jeremy at bitsweat.net
Wed Feb 28 19:28:45 EST 2007

On 2/28/07, Kirk Haines <wyhaines at gmail.com> wrote:
> On 2/28/07, Jeremy Kemper <jeremy at bitsweat.net> wrote:
> > This is true. However, his assertion is valid: it's a must for any web
> app
> > that uses blocking API calls, like executing queries using the native
> mysql
> > and postgres clients. That's just life with Ruby threads.
> I have oodles of dynamic web sites and applications that make blocking
> API calls yet can still sustain hit rates in the 50-200/second range
> (depending on the site) under a single mongrel.  They bear up just
> fine to bursty traffic when people are checking their fund prices in
> the evenings.

Great anecdote. I've had similar experience with Mongrel.

There are situations where clustering multiple backends is necessary,
> for sure, but it's possible to handle an exceptional amount of
> dynamic, db-interactive traffic in a single ruby process.

"It's a must" is too strong. I meant to illuminate that it's not just a
"must for Rails." That's true for other reasons.

For example: you have an operation that obtains a write lock on a db row and
does some work. Concurrent requests ought to just wait on the lock and
proceed when available, but Ruby threads will deadlock on the API call since
waiting on the lock prevents the worker thread that obtained it from

Whether this is an edge case or a common case is up to your application.

I think a preforking Mongrel would be the biggest positive change for Ruby
web app deployment since its introduction. Nearly zero config; just gem
install and go.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070228/9e4b72d5/attachment.html 

More information about the Mongrel-users mailing list