Rails - Jan 2006 - Mongrel HTTP Library 0.2.0 (Fast And RubyForgified)

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
http://www.zedshaw.com/

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

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.
:-)
> 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
http://www.zedshaw.com/

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

Zed Shaw wrote:
> 
> 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. :-)
> 
>> 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
> http://www.zedshaw.com/
> 
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

> 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?

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 Mornini

On Jan 31, 2006, at 3:08 PM, Rafael Szuminski 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?

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.

On 2/1/06, Tom Mornini <tmornini@infomania.com>
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.

On Jan 31, 2006, at 6:08 PM, Rafael Szuminski 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.  :-)

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

On Jan 31, 2006, at 6:31 PM, Tom Mornini 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
http://www.zedshaw.com/

On Jan 31, 2006, at 9:15 PM, Ben Myles 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
http://www.zedshaw.com/

On Jan 31, 2006, at 9:22 PM, Zed Shaw wrote:
> On Jan 31, 2006, at 9:15 PM, Ben Myles 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.
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 Szuminski.

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 :-)

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 Mornini

Tom Mornini wrote:
> On Jan 31, 2006, at 9:22 PM, Zed Shaw 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!

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