Rails - Mar 2006 - Mongrel Web Server 0.3.11 -- Edge Rails and Win32 Compliant

Hello Folks,

This is the big release of Mongrel that''s been in the works for a while
now
(well, like a week).  It is chock full of changes and features, but mostly
it syncs up the Win32 side of things, and validates that Edge Rails works
without problems.  It also features a more extensive and useful example of
the GemPlugins called mongrel_config.

First the usual stuff for people without a clue.

WHAT IS MONGREL?

Mongrel is a small fast little web server project trying to bring the speed
of FastCGI and the simplicity of WEBrick for deploying any Ruby web
application.  It already supports Ruby on Rails, Camping, and Nitro and
could soon support IOWA.  Since it is a regular old HTTP based server it can
be clustered, manipulated, and deployed like any other web server you use.

Check out the nifty website at:

http://mongrel.rubyforge.org/


TOP 10 REASONS TO USE MONGREL

10) It''s damn fast without being a pain to install.
9) It works on tons of platforms with active testing on Win32, FreeBSD,
Linux, OSX, and NetBSD.
8) It is probably the very best deployment solution for people doing Win32
Rails development, especially since it actively supports windows services
and has a reasonably nice management tool.
7) It''s fast enough that you could probably run your small to medium
size
Ruby web applications using just Mongrel and be perfectly happy.
6) It actively supports Rails style page caching which could give your
application a major performance boost without any extra deployment effort.
5) It uses an insanely correct HTTP parser which I''ve found blocks
quite a
few exploits.  This parser is also what makes Mongrel so Fast.
4) It has a great plugin system that lets you package your extensions as
gems and your users just "gem install and go".
3) It is LGPL so you thieves can make money (but I get Mongrel mods back!)
2) It supports and uses Camping.  Camping is cool.

And the best reason to use Mongrel is...

1) Isn''t a cool name like Mongrel enough?


INSTALLING

You might need sudo, you *will* need Ruby 1.8.4, and you''ll need a
compiler
(unless you''re on win32).

Simple enough.  If you have mongrel already try "gem upgrade".  If
that
causes problems then you might have to clear out gem_plugin, mongrel,
mongrel_config, and mongrel_status.  This is rare and typically only if
people have been tracking my development.

For newbies just do this:

 $ gem install mongrel
 $ gem install mongrel_config
 $ gem install mongrel_status  (if you want this)

That''s it.


NEW STUFF TO TRY IN 0.3.11

The 0.3.11 release features edge Rails support, some great functionality,
big stability improvements, some good docs for folks to start using, and
finally the beginning of a config tool implemented as a GemPlugin.  Most
importantly it completely supports Win32 again and the mongrel_config tool
actually works *better* in Win32.

= Documentation

If you haven''t seen it yet, check out
http://mongrel.rubyforge.org/docs/lighttpd.html For a good set of docs for
getting Mongrel up in a very fast production deployment running on one
machine.

Check out http://mongrel.rubyforge.org/docs/gem_plugin.html for docs on
writing your very own mongrel_rails commands as gem plugins.  The ability to
write your own handlers, filters, and potentially whole applications as
plugins coming soon.  Adventurous people could try doing a rails plugin by
adding "rails" as a dependency on their plugin gem.

Especially check out the gpgen tool for getting a mongrel plugin up with
minimal effort.

== Edge Rails

This release was tested with Edge Rails and several applications, but
I''d be
interested in more people living on the edge.

== Config Tool

If you''re on Unix (OSX too) or Windows you now have a new thing to play
with: mongrel_config.  Once you install the mongrel_config gem you get a new
command for mongrel_rails.  You can try it two ways depending on your
platform:

 UNIX:
    1) cd myrailsapp
    2) $ mongrel_rails configtool
    3) Hit the web page it says and try starting and stopping your rails
app.

 WIN32:
    1) $ mongrel_rails configtool
    2) Hit the web page and install new services, delete them, start them,
stop them, check out the start/stop logs, and view all of the service''s
parameters.  Yeah, win32 wins on this one.

And yes, win32 configtool doesn''t need to be in any rails directory,
which
means smart people will make a simple link that runs this in order to manage
their rails apps services.

== Camping

Mongrel now supports Camping a lot better and uses it extensively in the
mongrel_config plugin.   Camping is _why''s little micro-framework for
doing
web applications.  It''s perfect for little tools like the
mongrel_config
plugin.

If you''re interested in writing a little application and don''t
want a full
Rails app then try looking at the code to mongrel_config to get an idea.  It
works great, the only thing is that there''s tons of PFM in Camping that
seems to break Rails like crazy.  Camping == oil.  Rails == water. 
Don''t
mix.

== The Dreaded TCP Hack

Sean Treadway gave me a bit of hack code which jacks the OS listen queue
from the default (usually 5) to a whopping 1024.  This makes Mongrel handle
concurrency much better.  Give it a try and let me know how it works for
you.


THE FUTURE

I''ll be writing the filters feature and finally the configuration file
that
will let you configure any handlers and filters from a .yaml file.  This is
needed so that people can write plugins to give you special filters,
handlers, or whole applications (similar to configtool).

After this I''ll be talking with Luis to see if we can consolidate the
mongrel_rails_service and mongrel_rails by using the plugin system to
implement the commands.  We''ll also look at making the mongrel_config
more
advanced.

Finally I''m talking with the IOWA folks to roll their web app into the
Mongrel kennel.  Fun stuff!

Enjoy the release and feel free to shoot me your problems, praise, and any
features requests.

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

Hey Zed,

awesome thing! I''d been like, frantically waiting for this "ever
since" Mongrel stopped working with Edge a few days ago. Mongrel
was *the* thing missing for making Rails development not suck on
a 366-MHz-320MB-RAM iBook Clamsheel :-)

Just one question: do you think it''d be possible to get the Rails
people to update script/server, so that it could start Mongrel as
well?

Thanks for a great piece of software!

Best regards,
Raphael

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

Hi Zed

I am about to try Mongrel on windows and hope to use it in production for a
project.  Is it possible to use Mongrel with iis?   If so is there any
information on how to?

Sorry in advance if this is a stupid question!!

Thanks

Fraz



On 3/15/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
>
> Hello Folks,
>
> This is the big release of Mongrel that''s been in the works for a
while
> now
> (well, like a week).  It is chock full of changes and features, but mostly
> it syncs up the Win32 side of things, and validates that Edge Rails works
> without problems.  It also features a more extensive and useful example of
> the GemPlugins called mongrel_config.
>
> First the usual stuff for people without a clue.
>
> WHAT IS MONGREL?
>
> Mongrel is a small fast little web server project trying to bring the
> speed
> of FastCGI and the simplicity of WEBrick for deploying any Ruby web
> application.  It already supports Ruby on Rails, Camping, and Nitro and
> could soon support IOWA.  Since it is a regular old HTTP based server it
> can
> be clustered, manipulated, and deployed like any other web server you use.
>
> Check out the nifty website at:
>
> http://mongrel.rubyforge.org/
>
>
> TOP 10 REASONS TO USE MONGREL
>
> 10) It''s damn fast without being a pain to install.
> 9) It works on tons of platforms with active testing on Win32, FreeBSD,
> Linux, OSX, and NetBSD.
> 8) It is probably the very best deployment solution for people doing Win32
> Rails development, especially since it actively supports windows services
> and has a reasonably nice management tool.
> 7) It''s fast enough that you could probably run your small to
medium size
> Ruby web applications using just Mongrel and be perfectly happy.
> 6) It actively supports Rails style page caching which could give your
> application a major performance boost without any extra deployment effort.
> 5) It uses an insanely correct HTTP parser which I''ve found blocks
quite a
> few exploits.  This parser is also what makes Mongrel so Fast.
> 4) It has a great plugin system that lets you package your extensions as
> gems and your users just "gem install and go".
> 3) It is LGPL so you thieves can make money (but I get Mongrel mods back!)
> 2) It supports and uses Camping.  Camping is cool.
>
> And the best reason to use Mongrel is...
>
> 1) Isn''t a cool name like Mongrel enough?
>
>
> INSTALLING
>
> You might need sudo, you *will* need Ruby 1.8.4, and you''ll need a
> compiler
> (unless you''re on win32).
>
> Simple enough.  If you have mongrel already try "gem upgrade". 
If that
> causes problems then you might have to clear out gem_plugin, mongrel,
> mongrel_config, and mongrel_status.  This is rare and typically only if
> people have been tracking my development.
>
> For newbies just do this:
>
> $ gem install mongrel
> $ gem install mongrel_config
> $ gem install mongrel_status  (if you want this)
>
> That''s it.
>
>
> NEW STUFF TO TRY IN 0.3.11
>
> The 0.3.11 release features edge Rails support, some great functionality,
> big stability improvements, some good docs for folks to start using, and
> finally the beginning of a config tool implemented as a GemPlugin.  Most
> importantly it completely supports Win32 again and the mongrel_config tool
> actually works *better* in Win32.
>
> = Documentation
>
> If you haven''t seen it yet, check out
> http://mongrel.rubyforge.org/docs/lighttpd.html For a good set of docs for
> getting Mongrel up in a very fast production deployment running on one
> machine.
>
> Check out http://mongrel.rubyforge.org/docs/gem_plugin.html for docs on
> writing your very own mongrel_rails commands as gem plugins.  The ability
> to
> write your own handlers, filters, and potentially whole applications as
> plugins coming soon.  Adventurous people could try doing a rails plugin by
> adding "rails" as a dependency on their plugin gem.
>
> Especially check out the gpgen tool for getting a mongrel plugin up with
> minimal effort.
>
> == Edge Rails
>
> This release was tested with Edge Rails and several applications, but
I''d
> be
> interested in more people living on the edge.
>
> == Config Tool
>
> If you''re on Unix (OSX too) or Windows you now have a new thing to
play
> with: mongrel_config.  Once you install the mongrel_config gem you get a
> new
> command for mongrel_rails.  You can try it two ways depending on your
> platform:
>
> UNIX:
>     1) cd myrailsapp
>     2) $ mongrel_rails configtool
>     3) Hit the web page it says and try starting and stopping your rails
> app.
>
> WIN32:
>     1) $ mongrel_rails configtool
>     2) Hit the web page and install new services, delete them, start them,
> stop them, check out the start/stop logs, and view all of the
service''s
> parameters.  Yeah, win32 wins on this one.
>
> And yes, win32 configtool doesn''t need to be in any rails
directory, which
> means smart people will make a simple link that runs this in order to
> manage
> their rails apps services.
>
> == Camping
>
> Mongrel now supports Camping a lot better and uses it extensively in the
> mongrel_config plugin.   Camping is _why''s little micro-framework
for
> doing
> web applications.  It''s perfect for little tools like the
mongrel_config
> plugin.
>
> If you''re interested in writing a little application and
don''t want a full
> Rails app then try looking at the code to mongrel_config to get an
> idea.  It
> works great, the only thing is that there''s tons of PFM in Camping
that
> seems to break Rails like crazy.  Camping == oil.  Rails == water. 
Don''t
> mix.
>
> == The Dreaded TCP Hack
>
> Sean Treadway gave me a bit of hack code which jacks the OS listen queue
> from the default (usually 5) to a whopping 1024.  This makes Mongrel
> handle
> concurrency much better.  Give it a try and let me know how it works for
> you.
>
>
> THE FUTURE
>
> I''ll be writing the filters feature and finally the configuration
file
> that
> will let you configure any handlers and filters from a .yaml file.  This
> is
> needed so that people can write plugins to give you special filters,
> handlers, or whole applications (similar to configtool).
>
> After this I''ll be talking with Luis to see if we can consolidate
the
> mongrel_rails_service and mongrel_rails by using the plugin system to
> implement the commands.  We''ll also look at making the
mongrel_config more
> advanced.
>
> Finally I''m talking with the IOWA folks to roll their web app into
the
> Mongrel kennel.  Fun stuff!
>
> Enjoy the release and feel free to shoot me your problems, praise, and any
> features requests.
>
> Zed A. Shaw
> http://www.zedshaw.com/
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060315/ee9b9f9d/attachment.html

Zed Shaw wrote:
> Mongrel is a small fast little web server project trying to bring the speed
> of FastCGI and the simplicity of WEBrick for deploying any Ruby web
> application.  It already supports Ruby on Rails, Camping, and Nitro and
> could soon support IOWA.  Since it is a regular old HTTP based server it
can
> be clustered, manipulated, and deployed like any other web server you use.
>
> Check out the nifty website at:
>
> http://mongrel.rubyforge.org/
>
>
> TOP 10 REASONS TO USE MONGREL
>   
This looks great! I''ve been checking out the Mongrel pages and it looks
like a great project.

I was curious ... is anyone using this in production right now, or is it 
(as the version number suggests) not quite ready for that?  If you''re 
using it in production, how is it faring?  I''m having some problems
with
FCGI (on a specific machine that''s admittedly configured kind of oddly)
and I''d love to try an alternative, but only if it''s something
that''s
known to be able to keep running under at least a modest load for a 
reasonable amount of time (certainly more than the 2 days I''m 
experiencing with FCGI right now; I''ll post an update if my attempted 
fixes seem to do better).

Jen

Like others here, I''d like to start using Mongrel for a production 
application. I''m currently planning to run several instances behind 
LighTPD as outlined in the Mongrel documentation. By far, this is the 
easiest method I''ve found to serve up a Rails App on Windows (after 
trying many other approaches with FCGI, etc). Awesome work, Zed!

I''m kind of curious what others are seeing when running httperf 
benchmarks against the LighTPD/Mongrel setup. I''m getting results on 
Windows that seem pretty low. I configured a simple "Hello, world!" 
Rails app and ran it on three different setups using httperf to 
benchmark the response rate.

Mac OS X 10.4.4 (1.33Ghz G4, 768MB RAM), using Locomotive 
(LighTPD/FCGI):

8.5 requests/second

Kubuntu 5.10 (1.6Ghz AMD Sempron 64, 1GB RAM), using ruby 1.8.4, 
LighTPD/Mongrel:

16.6 requests/second

Windows XP SP2 (3Ghz Intel P4, 1GB RAM), using ruby 1.8.4, 
Cygwin/LighTPD/Mongrel:

0.8 requests/second

Obviously, all three setups are wildly different -- these are just what 
I have access to in the development environment. Even so, It seems 
_really_ odd that the Windows numbers would be so low. Is there 
something I''m missing? Rails is the same version on all three setups,
as
is the LighTPD config. The only thing I can think of that might be 
causing the slowdown is Cygwin. I''d be much obliged for any insights.

FWIW, I''m running httperf using the following command:

httperf --port 3000 --server 192.168.x.x --num-conns 300 --uri /test

/test, of course, is the little "Hello, world" rails app.

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

In my experience, Ruby + Rails runs dog slow on Windows. I get roughly 4 to
8 req/second on Windows with either Apache + FCGI, Light + SCGI, or Mongrel.

I was able to get 19 req/sec with Apache+FCGI but I had to use 4 dispatchers
and I had to make sure that my shebang line in dispatch.fcgi called rubyw
instead of ruby.

I figure if you can get 6 req/second, you''ll be fine for light-traffic
sites.

I''ve asked this question before, but is there anything that can be done
to
speed up Ruby on Windows? Even running console or irb takes a lot longer
than it does on Linux,

On 3/22/06, Jon Fuller <ratchetcat@yahoo.com>
wrote:
>
> Like others here, I''d like to start using Mongrel for a production
> application. I''m currently planning to run several instances
behind
> LighTPD as outlined in the Mongrel documentation. By far, this is the
> easiest method I''ve found to serve up a Rails App on Windows
(after
> trying many other approaches with FCGI, etc). Awesome work, Zed!
>
> I''m kind of curious what others are seeing when running httperf
> benchmarks against the LighTPD/Mongrel setup. I''m getting results
on
> Windows that seem pretty low. I configured a simple "Hello,
world!"
> Rails app and ran it on three different setups using httperf to
> benchmark the response rate.
>
> Mac OS X 10.4.4 (1.33Ghz G4, 768MB RAM), using Locomotive
> (LighTPD/FCGI):
>
> 8.5 requests/second
>
> Kubuntu 5.10 (1.6Ghz AMD Sempron 64, 1GB RAM), using ruby 1.8.4,
> LighTPD/Mongrel:
>
> 16.6 requests/second
>
> Windows XP SP2 (3Ghz Intel P4, 1GB RAM), using ruby 1.8.4,
> Cygwin/LighTPD/Mongrel:
>
> 0.8 requests/second
>
> Obviously, all three setups are wildly different -- these are just what
> I have access to in the development environment. Even so, It seems
> _really_ odd that the Windows numbers would be so low. Is there
> something I''m missing? Rails is the same version on all three
setups, as
> is the LighTPD config. The only thing I can think of that might be
> causing the slowdown is Cygwin. I''d be much obliged for any
insights.
>
> FWIW, I''m running httperf using the following command:
>
> httperf --port 3000 --server 192.168.x.x --num-conns 300 --uri /test
>
> /test, of course, is the little "Hello, world" rails app.
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060322/b1bce24c/attachment.html

Yes, I''ve been carefully scrubbing the Mongrel code and testing
performance
on all of them.  The unofficial status right now is this:

Linux:  Damn fast, compared to WEBrick.
FreeBSD:  Damn fast, compared to WEBrick, slightly slower than Linux.
MacOSX:  Faster than webrick, still slow as dirt compared to Linux.
Win32:  Marginally faster than webrick, some people report webrick faster.

With Win32 and OSX I''m seeing if just recompiling ruby improves things
the
way it did for FreeBSD.  Also the latest pre-release of Mongrel may (or may
not) improve things further for people.

If you''d like to try the pre-release (which has oodles of features,
check
the Configurator rdoc for a taste) try this:

  $ gem uninstall mongrel
  $ gem uninstall gem_plugin
  $ gem install mongrel --source=http://mongrel.rubyforge.org/releases/

And you''ll be able to run your tests again to get an idea of how this
release impacts it.  Let me know if it''s worse or better.

The main advantage though of Mongrel on win32 is that it''s dead dead
dead
easy to setup say 10 mongrel services on different ports and parallelize the
hell out of them.  There''s even an option to use CPU affinity to assign
each
Mongrel to a set CPU out of a group, which is something you don''t get
with
the POSIX systems.

At some point though people need to start complaining about Ruby.  As much
as folks on the ruby-talk mailing list hate to talk about it they''re
going
to have to do something about Ruby''s speed.  I''d say
I''m pushing the
envelope of high-performance Ruby pretty far and while I''m going to do
everything humanly possible to make Mongrel fast all hell, it will really
take people complaining to the *Ruby* team to make things run much faster.

In other words, I''m gonna try a few more tweaks, and possibly check-out
if
compiling on OSX and Win32 WITHOUT pthreads helps (like it did with
FreeBSD).  But, in the end, someone will just have to make Ruby faster.  My
only alternative is what I''m doing now which is writing critical parts
in C.

Anyway, try out the pre-releases and let me know if that improves things.
Otherwise your metrics are about right with the win32 metric being *way*
lower than what I see.

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


On 3/22/06 2:55 PM, "Jon Fuller" <ratchetcat@yahoo.com> wrote:
> Like others here, I''d like to start using Mongrel for a production
> application. I''m currently planning to run several instances
behind
> LighTPD as outlined in the Mongrel documentation. By far, this is the
> easiest method I''ve found to serve up a Rails App on Windows
(after
> trying many other approaches with FCGI, etc). Awesome work, Zed!
> 
> I''m kind of curious what others are seeing when running httperf
> benchmarks against the LighTPD/Mongrel setup. I''m getting results
on
> Windows that seem pretty low. I configured a simple "Hello,
world!"
> Rails app and ran it on three different setups using httperf to
> benchmark the response rate.
> 
> Mac OS X 10.4.4 (1.33Ghz G4, 768MB RAM), using Locomotive
> (LighTPD/FCGI):
> 
> 8.5 requests/second
> 
> Kubuntu 5.10 (1.6Ghz AMD Sempron 64, 1GB RAM), using ruby 1.8.4,
> LighTPD/Mongrel:
> 
> 16.6 requests/second
> 
> Windows XP SP2 (3Ghz Intel P4, 1GB RAM), using ruby 1.8.4,
> Cygwin/LighTPD/Mongrel:
> 
> 0.8 requests/second
> 
> Obviously, all three setups are wildly different -- these are just what
> I have access to in the development environment. Even so, It seems
> _really_ odd that the Windows numbers would be so low. Is there
> something I''m missing? Rails is the same version on all three
setups, as
> is the LighTPD config. The only thing I can think of that might be
> causing the slowdown is Cygwin. I''d be much obliged for any
insights.
> 
> FWIW, I''m running httperf using the following command:
> 
> httperf --port 3000 --server 192.168.x.x --num-conns 300 --uri /test
> 
> /test, of course, is the little "Hello, world" rails app.