«

Hello All,

Yet another release of Mongrel proudly pushed out for everyone to review an=
d
comment on. This time though, I've done up a little website that's *way*
better than the plan Rdoc that used to stand in for the site like a
one-legged leper.

* http://mongrel.rubyforge.net/

As you should already know, Mongrel is a fast HTTP server and library for
Ruby partially written in C. It supports running Ruby on Rails, Camping,
and Og+Nitro applications as well as featuring a simple API for others to
use in their own frameworks. Performance is usually much higher than
WEBrick while the features are kept much lower.


=3D=3D 0.3.1 Changes

* This release fixes a *huge* bug in the Rails support where the
Content-length was very very wrong. People who had weird problems
downloading images should try this release and let me know the results.

* It features a new command and plugin system (thanks to pluginfactory) wit=
h
an initial start and stop command for Ruby on Rails.

* New site that was basically stolen from all sorts of Creative Commons
licensed sources. Please read the attributions page (
http://mongrel.rubyforge.org/attributions.html) so they get credit.

* Dependency problems with daemons gem solved.


=3D=3D The New Rails Runner

This release features a mongrel_rails script that has start and stop
commands as well as full options for dictating it's configuration. Simply
do the following:

$ sudo gem install mongrel
$ cd myrailsapp
$ mongrel_rails start -d

Which runs Mongrel in the background. You can stop it with:

$ mongrel_rails stop

And you=B9re all set. You can pass the start and stop commands the -h option
to find out all the possible options.


=3D=3D=3D Win32 Folks

The only thing you people need to do right now is avoid the -d option for
start. Win32 doesn=B9t support POSIX fork so it won=B9t go into the background.
I=B9ll be adding support for making Mongrel a service in a few releases.

There might be other Process specific calls the blow up on win32. Let me
know since..ehem..I didn't really test this on win32. Sorry.


=3D=3D The Next Release

I'll be grabbing all the various Rails applications I can and begin testing
Mongrel against them. If anyone is building an application and is
interested in testing Mongrel with their gear then shoot me an e-mail.
There is one outstanding bug with the Rails support which I have to fix, bu=
t
otherwise it's working reasonably well.

Any suggestions for documentation people want are more than welcome.

Finally, I'm looking at a caching mechanism that would involve dynamically
storing gzip and regular versions of all returned content into a memcached.
I have a small prototype kind of working that does this, but I'm interested
in people's ideas for what they'd like in a caching system that's between
Rails page caching and fully dynamic content.


=3D Love Your Dog?

I'm looking for people who want their buddy featured on the Mongrel site.
Just post a photo via some photo posting site and let me know where it is.
I'll make a page for all the "mongrels" out there. 'Cause dogs rule.


Zed A. Shaw
http://www.zedshaw.com/

Zed Shaw wrote:

> As you should already know, Mongrel is a fast HTTP server and library
> for
> Ruby partially written in C. It supports running Ruby on Rails

Does it handle multiple concurrent Rails requests (threads)?

--
Posted via http://www.ruby-forum.com/.

D=C5=88a Nede=C4=BEa 12 Febru=C3=A1r 2006 23:06 Andreas S. nap=C3=ADsal:
> Zed Shaw wrote:
> > As you should already know, Mongrel is a fast HTTP server and library
> > for
> > Ruby partially written in C. It supports running Ruby on Rails
>
> Does it handle multiple concurrent Rails requests (threads)?

The documentation seems to indicate that Mongrel is a threading server with=
20=20
worker thread. So I'd bet on "yes".

David Vallner

Yes, it handles concurrent requests *except* for right when it runs the
actual Rails dispatcher. Rails isn't thread safe and so there needs to be a
big sync lock around the whole thing to keep Rails from peeing in it's pants
like a schoolgirl.

Otherwise there are a fixed number of worker threads that simply wait on a
queue of requests to process and they work with those in parallel. Right
after Dispatcher is done the lock is released and the required IO is sent
back via these worker threads.

It can handle a reasonably good load with this, but probably still needs
some tuning.

Zed A. Shaw
http://www.zedshaw.com/


On 2/12/06 5:06 PM, "Andreas S." <> wrote:

> Zed Shaw wrote:
>
>> As you should already know, Mongrel is a fast HTTP server and library
>> for
>> Ruby partially written in C. It supports running Ruby on Rails
>
> Does it handle multiple concurrent Rails requests (threads)?

D=C5=88a Pondelok 13 Febru=C3=A1r 2006 01:38 Zed Shaw nap=C3=ADsal:
> Yes, it handles concurrent requests *except* for right when it runs the
> actual Rails dispatcher. Rails isn't thread safe and so there needs to be
> a big sync lock around the whole thing to keep Rails from peeing in it's
> pants like a schoolgirl.
>

I might be easy to amuse, but I'm getting hilarious mildly (well, not reall=
y=20
mildly) pornographical mental images of ruby-talk members involving=20
schoolgirl costumes and urination.

Which probably noone wanted to know. Weep.

> Otherwise there are a fixed number of worker threads that simply wait on a
> queue of requests to process and they work with those in parallel. Right
> after Dispatcher is done the lock is released and the required IO is sent
> back via these worker threads.
>

Hmm. Is fastCGI / SCGI support on the roadmap for these cases?

David Vallner

Zed Shaw wrote:
> Yes, it handles concurrent requests *except* for right when it runs the
> actual Rails dispatcher. Rails isn't thread safe and so there needs to be a
> big sync lock around the whole thing to keep Rails from peeing in it's pants
> like a schoolgirl.

Ah, that incontinence problem again.

So does that imply that one might actually want to run several instances
of Mongrel behind a load-balancing lighttpd proxy? Since most of the
time (for my app at least) is going to be spent within Rails,
effectively Mongrel's single-threaded.

Zed Shaw wrote:
> Yet another release of Mongrel proudly pushed out for everyone to review and
> comment on. This time though, I've done up a little website that's *way*
> better than the plan Rdoc that used to stand in for the site like a
> one-legged leper.
>
> * http://mongrel.rubyforge.net/

Such nice design, Zed. You're so Web 2.0 I can barely stand it.

Anyway, it's http://mongrel.rubyforge.org/ , though I'm sure everybody
can figure that out.

f.

D=C5=88a Pondelok 13 Febru=C3=A1r 2006 03:31 Michael Schoen nap=C3=ADsal:
> Zed Shaw wrote:
> > Yes, it handles concurrent requests *except* for right when it runs the
> > actual Rails dispatcher. Rails isn't thread safe and so there needs to
> > be a big sync lock around the whole thing to keep Rails from peeing in
> > it's pants like a schoolgirl.
>
> Ah, that incontinence problem again.
>
> So does that imply that one might actually want to run several instances
> of Mongrel behind a load-balancing lighttpd proxy? Since most of the
> time (for my app at least) is going to be spent within Rails,
> effectively Mongrel's single-threaded.

You could possibly directly wire lighttpd to Rails then, what with the New!=
=20
Shiny! SCGI runner around IIRC.

David Vallner

> You could possibly directly wire lighttpd to Rails then, what with the New!
> Shiny! SCGI runner around IIRC.

That's how we've been running for the past few months (thanks Zed!), and
it works well. Mongrel's a step forward though, cause it makes it easier
to verify that a specific process is working properly since you can hit
it directly with a browser, something you can't do with an scgi process.

On 13/02/06, Tom Cloyd <> wrote:
> Yeah, well, too bad I'm given absolutely no reason to click past the fron=
t
> page. Don't you just love mystery meat? Not really.


Did you miss the 'Mongrel is a fast HTTP library and server for Ruby' bit?

--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/