[ANN] Mongrel HTTP Library 0.2.0 (Fast And RubyForgified)

Rails
1

Hi Everyone,

I’m happy to announce the 0.2.0 release of Mongrel – the fastest
HTTP 1.1 library Ruby has yet.

http://mongrel.rubyforge.org/ – ruby docs lame page.
http://rubyforge.org/projects/mongrel/ – project page.

Special thanks to Tom Copland for setting up my RubyForge goodness,
and to Why for kicking in time to get the Camping examples up to snuff.

This release should strike a good balance between being fast and
being stable on all platforms.

== Gems And Source

You can get this release of Mongrel via RubyGems in the usual way:

gem install mongrel

Please let me know if this don’t install. You can also hit the
project page and download a full .tgz source file if you hate RubyGems.

== Status

This release mostly just focuses on the core of Mongrel. I’ve done
just about everything I know to make it the fastest thing possible
short of sacrificing goats and small children (but there was this one
dude on IRC). I’ll leave it to others to compare for now but the
main purpose of this release is to do any final fine tunings and
really pound on it to make it stable.

The other major change is that the HttpResponse class is now fully
functioning and should be easy for people to use. It does not
support the CGI library yet but I’ve got devious evil plans to set my
skills on the CGI library as well.

== Example

This example is from the examples/simpletest.rb file:

require ‘mongrel’

class SimpleHandler < Mongrel::HttpHandler
def process(request, response)
response.start(200) do |head,out|
head[“Content-Type”] = “text/plain”
out.write(“hello!\n”)
end
end
end

h = Mongrel::HttpServer.new(“0.0.0.0”, “3000”)
h.register(“/test”, SimpleHandler.new)
h.run.join

Doesn’t really do much but demonstrates the main meat of the system.
Why has also written some Camping (http://rubyforge.org/projects/
camping) samples which should work with the svn version of Camping.

== Next Steps

I’d love for people to break the hell out of it and post me some bug
reports. I’ve tried to do everything I can, but I’m going to get
ahold of some HTTP fuzzing stuff and see if I can’t do any further
damage.

I’m also looking for smart people who might have opinions on Mongrel,
what it does, and specifically how you can see using it with your web
application framework. Feel free to join the Mongrel mailing list at
http://rubyforge.org/mailman/listinfo/mongrel-users and start tossing
the ideas around.

Enjoy and let me know what you think.

Zed A. Shaw

2

hey zed,

no one need to inform you about your mad skillz, but I thought (in
addition to that) I’d throw this in:

wouldn’t it be nice to be able to run a rails app that was itself a
production quality webserver? I have always pined for a single
integrated framework that spoke HTTP properly and with very good
performance. A lot of mucking about with CGI<->Webserver would be gone
if that were done correctly… and it smells like you’re stepping in
that direction.

/bow

_a

3

On Jan 31, 2006, at 3:30 AM, alex black wrote:

hey zed,

no one need to inform you about your mad skillz, but I thought (in
addition to that) I’d throw this in:

Thanks, I guess my madness at least has some side benefits. :slight_smile:

wouldn’t it be nice to be able to run a rails app that was itself a
production quality webserver? I have always pined for a single
integrated framework that spoke HTTP properly and with very good
performance. A lot of mucking about with CGI<->Webserver would be
gone if that were done correctly… and it smells like you’re
stepping in that direction.

That’s one of three general directions, but actually the first one is
to simply make it easier to host a web app fast as hell behind any
web server or proxy server that supports basic HTTP.

The second medium term goal is what you’re talking about. I think
Mongrel should be able to serve a whole web application the same way
WEBrick does but since it uses C in key places I’m able to make it
much faster.

The really far out goal is to try building something different from
the other scripting language HTTP servers out there–something that
shows off what a dynamic language can do. I’ve got ideas for stuff
I’ve always wanted in a server like this. A good example is dynamic
single sign-on support right in the server. Most of these ideas are
really wild and half are incredibly stupid, but it’s just fantasy
stuff anyway.

I’m also looking to move some of the things I’ve done in Mongrel back
into SCGI Rails Runner to improve that as well.

Zed A. Shaw

4

Hey Zed,

Just a another quick ping to say right on and keep it up.

Coming from a Java world I find myself longing for a powerful,
full-featured container
into which I can plugs my apps. I think it’s sad that the rails
community matter-of-factly
says that webrick is for development only. There must be some way to
make a
multi-threaded, long-running daemon process for serving ruby apps
possible… sounds like
you’re on the trail.

b

5

Oh, I like the way this is going!

If hosting a production Rails app was as easy as running
script/server, and the performance was even 25% that of
apache/lighty + FCGI/SCGI, this would be incredibly good
news for Rails.

Particularly so if the same server could be used for
development!

Really, really good news.

–
– Tom M.

6

That’s one of three general directions, but actually the first one is
to simply make it easier to host a web app fast as hell behind any
web server or proxy server that supports basic HTTP.

How far do you think the project is from hosting a rails app a la
webrick?

7

I think the performance (for a Rails app) should eventually be able to
match what you would get running lighttpd + scgi / fastcgi.

Even though Mongrel will probably never be as fast as lighttpd serving
http requests, the bottleneck will be Rails itself, and Mongrel should
be able to keep ahead of that.

8

On Jan 31, 2006, at 6:08 PM, Rafael S. wrote:

That’s one of three general directions, but actually the first one is
to simply make it easier to host a web app fast as hell behind any
web server or proxy server that supports basic HTTP.

How far do you think the project is from hosting a rails app a la
webrick?

Basically as soon as I get off my ass and actually write the rails
runner code. But, don’t let that stop anybody from taking a note
from the Camping and Nitro folks to write it for me. :slight_smile:

Zed A. Shaw

9

On Jan 31, 2006, at 6:31 PM, Tom M. wrote:

If hosting a production Rails app was as easy as running
script/server, and the performance was even 25% that of
apache/lighty + FCGI/SCGI, this would be incredibly good
news for Rails.

Particularly so if the same server could be used for
development!

No promises on the first performance, but I’m pretty sure it’ll be
smoking for no other reason than I’ve already done this three times
before.

But the second will be a no brainer.

Zed A. Shaw

10

On Jan 31, 2006, at 9:15 PM, Ben M. wrote:

Even though Mongrel will probably never be as fast as lighttpd serving
http requests, the bottleneck will be Rails itself, and Mongrel should
be able to keep ahead of that.

This is the biggest problem with performance in any of the Ruby web
app frameworks. No matter how fast I make Mongrel, at some point
it’s gotta run Rails/Camping/Nitro and then things just crawl. The
advantage of Mongrel is it will at least remove most overhead, and
I’m shooting to have some wicked dynamic caching in there, so it
should be able to help with the performance problems.

Zed A. Shaw

11

Tom M. wrote:

On Jan 31, 2006, at 9:22 PM, Zed S. wrote:

In other words, I don’t see performance relative to Apache/Lighttpd +
FCGI/SCGI
as the most important problem. Instead, I see the complexity of
installing
Apache/Lighttpd + FCGI/SCGI as a problem much more in need to
solving.

Here here. Especially on the Windows side with existing Apache + PHP
installs that you don’t want to impact to run Rails apps!

12

On Jan 31, 2006, at 9:22 PM, Zed S. wrote:

frameworks. No matter how fast I make Mongrel, at some point it’s
gotta
run Rails/Camping/Nitro and then things just crawl. The advantage of
Mongrel is it will at least remove most overhead, and I’m shooting to
have some wicked dynamic caching in there, so it should be able to
help
with the performance problems.

Not sure I understand you Zed.

Do you mean that Mongrel will be slower than Apache/Lighttpd + FCGI/
SCGI + Rails
or do you mean that anything involving Rails is slow?

I’m sure that it will always be slower than Apache/Lighttpd + FCGI/
SCGI, and I’m
also sure that it doesn’t need to be fantastically slower due to
small amount of
HTTP processing -vs- Rails work, as pointed out by Rafael S…

But…that’s a problem that will likely resolve itself in one or more
of the
following manners:

  1. Rails performance enhancements
  2. Ruby performance enhancements
  3. Faster hardware :slight_smile:

In other words, I don’t see performance relative to Apache/Lighttpd +
FCGI/SCGI
as the most important problem. Instead, I see the complexity of
installing
Apache/Lighttpd + FCGI/SCGI as a problem much more in need to
solving. Why not
make Mongrel a special purpose Rails web server, capable of
development and
production modes, and eliminating the need for FCGI + SCGI entirely!

I think that if you could create a very specialized HTTP server that
would be
capable of serving 80% of the commercial web sites created in RoR
(from a
performance perspective, that is…single server or virtual server
for everything),
and make it as easy to setup and run as WEBrick is currently, then
it’s not hard
to imagine Mongrel replacing (or augmenting) WEBrick in the Rails
distro, and many
thousands of Rails applications running on Mongrel over the next
several years.

If it’s “fast enough”, and simple to install, then it will get a lot
of use.

–
– Tom M.