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
Rafael Szuminski
2006-Jan-31 23:08 UTC
[ANN] Mongrel HTTP Library 0.2.0 (Fast And RubyForgified)
> 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 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/.
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 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/