Forum: Ruby on Rails Mongrel Web Server 0.3.11 -- Edge Rails and Win32 Compliant

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-03-15 09:44
(Received via mailing list)
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/
77961c972c437d6801714f45c3f2cc3c?d=identicon&s=25 Raphael Schmid (rapha)
on 2006-03-15 11:22
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
Cf80d0758047e94940444feadf82a9bf?d=identicon&s=25 frazer horn (Guest)
on 2006-03-15 16:13
(Received via mailing list)
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
114a64bf4e0cb600120f348b6447c258?d=identicon&s=25 Jennyw Jennyw (jennyw)
on 2006-03-15 23:24
(Received via mailing list)
Zed Shaw wrote:
>
> 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
829d692dfbd5764f0543fe18be9b964a?d=identicon&s=25 Jon Fuller (ratchetcat)
on 2006-03-22 20:55
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.
6ef8cb7cd7cd58077f0b57e4fa49a969?d=identicon&s=25 Brian Hogan (Guest)
on 2006-03-22 21:10
(Received via mailing list)
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,
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-03-24 06:02
(Received via mailing list)
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/
This topic is locked and can not be replied to.