Would you bother to setup a fastcgi for a "intranet accessible" application that is like to get < 100 hits a day? David
It might be, but you also might want to look into Mongrel http://mongrel.rubyforge.org/. Michael
On Mon, 2006-02-27 at 05:01 -0500, David Corbin wrote:> Would you bother to setup a fastcgi for a "intranet accessible" application > that is like to get < 100 hits a day? >---- wasn''t that difficult to set up actually - if you are asking apache.cgi vs. apache.fcgi If you are asking apache.fcgi vs. webrick, the I would say yes because apache is a service where webrick is an application and requires user intervention (start/stop/cleanup etc.) Craig
On Feb 27, 2006, at 2:28 AM, Michael Trier wrote:> It might be, but you also might want to look into Mongrel > http://mongrel.rubyforge.org/. > > Michael > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >Yes, I highly reccomend mongrel for just this type of thing. It has a comand line interface to start it as a service or daemon and then stop or restart it later. And it is performing very very well in my tests. I think its perfect for intranet type apps like this. Cheers- -Ezra Zygmuntowicz Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 ezra@yakima-herald.com
On Feb 27, 2006, at 6:56 AM, Craig White wrote:> On Mon, 2006-02-27 at 05:01 -0500, David Corbin wrote: >> Would you bother to setup a fastcgi for a "intranet accessible" >> application >> that is like to get < 100 hits a day? >> > ---- > wasn''t that difficult to set up actually - if you are asking > apache.cgi > vs. apache.fcgi > > If you are asking apache.fcgi vs. webrick, the I would say yes because > apache is a service where webrick is an application and requires user > intervention (start/stop/cleanup etc.)Lies! Just have it daemonize itself. I serve over two million image hits a day via WEBrick and startup and shutdown are handled by FreeBSD''s rc.subr just like apache. -- Eric Hodel - drbrain@segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com
Hi, this is very good information in terms of benchmarks because I definitely need to provide similar information to clients when I recommend RoR. -Conrad On 2/27/06, Eric Hodel <drbrain@segment7.net> wrote:> On Feb 27, 2006, at 6:56 AM, Craig White wrote: > > > On Mon, 2006-02-27 at 05:01 -0500, David Corbin wrote: > >> Would you bother to setup a fastcgi for a "intranet accessible" > >> application > >> that is like to get < 100 hits a day? > >> > > ---- > > wasn''t that difficult to set up actually - if you are asking > > apache.cgi > > vs. apache.fcgi > > > > If you are asking apache.fcgi vs. webrick, the I would say yes because > > apache is a service where webrick is an application and requires user > > intervention (start/stop/cleanup etc.) > > Lies! > > Just have it daemonize itself. > > I serve over two million image hits a day via WEBrick and startup and > shutdown are handled by FreeBSD''s rc.subr just like apache. > > -- > Eric Hodel - drbrain@segment7.net - http://blog.segment7.net > This implementation is HODEL-HASH-9600 compliant > > http://trackmap.robotcoop.com > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Eric Hodel wrote:> I serve over two million image hits a day via WEBrick and startup and > shutdown are handled by FreeBSD''s rc.subr just like apache.So what about the mythical "mutex on each request" that WEBrick has? You don''t ever have long page waits? It never crashes? Is this one instance of WEBrick handling all those hits? I ask because I''ve wished for a web container to run my rails apps in, and WEBrick could be that other than for all the stern warnings about it not being suitable for production. (Been meaning to check out Mongrel too... but I''m still on 1.82) b
On Feb 27, 2006, at 9:55 PM, Ben Munat wrote:> Eric Hodel wrote: >> I serve over two million image hits a day via WEBrick and startup >> and shutdown are handled by FreeBSD''s rc.subr just like apache. > > So what about the mythical "mutex on each request" that WEBrick has?I don''t know about Rails, but no such thing exists in WEBrick. (Note that I''m not using WEBrick to serve Rails requests, I''m using it for "image hits".)> You don''t ever have long page waits?Do you consider ~ 50-60ms long? A typical request is handled in the 10ms-25ms range. There still may be a few optimizations I can make in the image lookup code that will reduce the standard deviation.> It never crashes?USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND www 6036 2.0 0.5 25268 10040 ?? S Sun11PM 23:00.12 /usr/ local/bin/rub No.> Is this one instance of WEBrick handling all those hits?I fork 8 processes per machine on three machines to distribute the load a little better since static image requests are very bursty and I have machines with multiple CPUs. I may cut it back to 6 or 4 processes now that I correctly handle conditional HTTP requests to save on memory. (2% CPU is high for these processes.)> I ask because I''ve wished for a web container to run my rails apps > in, and WEBrick could be that other than for all the stern warnings > about it not being suitable for production.I can''t tell you if Rails + WEBrick is suitable for serving high- volume traffic or not, I haven''t looked. WEBrick itself is certainly suitable for high-volume traffic when you write your servlets correctly (and, possibly, fork()). Rails may simply be missing something that allows it to run well multi-threaded.> (Been meaning to check out Mongrel too... but I''m still on 1.82)If I can serve static images with a lookup in MogileFS in 12ms and Apache can serve static content without any lookups straight off disk in 6ms I don''t see what benefit Mongrel would give me. My speed boost comes from using sendfile(). WEBrick makes it easy to match a URL with a File so I can pass it right in. -- Eric Hodel - drbrain@segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com
Eric Hodel wrote:> On Feb 27, 2006, at 9:55 PM, Ben Munat wrote: >> So what about the mythical "mutex on each request" that WEBrick has? > > I don''t know about Rails, but no such thing exists in WEBrick. (Note > that I''m not using WEBrick to serve Rails requests, I''m using it for > "image hits".)Duh... helps if I read more carefully. The passage in AWDWR is: [WEBrick is] not a particulary attractive approach for heavy-duty use. One of the reasons is the lack of thread safety in *ActionPack* (emphasis mine), which forces WEBrick to place a mutex at the gate of dynamic requests..." So, it is a problem in rails...... on the other hand, this is a rails list so I can see how I''d be thinking about that. :-) Oh and I''m mostly interested in mongrel as a "container" (ala a Java servlet container) for my rails apps... I''m starting to see how that''s not totally essential, but I think it''ll be nice to have as an option. b> >> You don''t ever have long page waits? > > > Do you consider ~ 50-60ms long? A typical request is handled in the > 10ms-25ms range. > > There still may be a few optimizations I can make in the image lookup > code that will reduce the standard deviation. > >> It never crashes? > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > www 6036 2.0 0.5 25268 10040 ?? S Sun11PM 23:00.12 /usr/ > local/bin/rub > > No. > >> Is this one instance of WEBrick handling all those hits? > > > I fork 8 processes per machine on three machines to distribute the load > a little better since static image requests are very bursty and I have > machines with multiple CPUs. I may cut it back to 6 or 4 processes now > that I correctly handle conditional HTTP requests to save on memory. > (2% CPU is high for these processes.) > >> I ask because I''ve wished for a web container to run my rails apps >> in, and WEBrick could be that other than for all the stern warnings >> about it not being suitable for production. > > > I can''t tell you if Rails + WEBrick is suitable for serving high- volume > traffic or not, I haven''t looked. WEBrick itself is certainly suitable > for high-volume traffic when you write your servlets correctly (and, > possibly, fork()). Rails may simply be missing something that allows > it to run well multi-threaded. > >> (Been meaning to check out Mongrel too... but I''m still on 1.82) > > > If I can serve static images with a lookup in MogileFS in 12ms and > Apache can serve static content without any lookups straight off disk > in 6ms I don''t see what benefit Mongrel would give me. > > My speed boost comes from using sendfile(). WEBrick makes it easy to > match a URL with a File so I can pass it right in. >
Ben Munat wrote:> Eric Hodel wrote: >> On Feb 27, 2006, at 9:55 PM, Ben Munat wrote: >>> So what about the mythical "mutex on each request" that WEBrick has? >> >> I don''t know about Rails, but no such thing exists in WEBrick. (Note >> that I''m not using WEBrick to serve Rails requests, I''m using it for >> "image hits".) > > Duh... helps if I read more carefully. The passage in AWDWR is: [WEBrick > is] not a particulary attractive approach for heavy-duty use. One of the > reasons is the lack of thread safety in *ActionPack* (emphasis mine), > which forces WEBrick to place a mutex at the gate of dynamic requests..." > > So, it is a problem in rails...... on the other hand, this is a rails > list so I can see how I''d be thinking about that. :-) > > Oh and I''m mostly interested in mongrel as a "container" (ala a Java > servlet container) for my rails apps... I''m starting to see how that''s > not totally essential, but I think it''ll be nice to have as an option.As I understand it, the mutex is in Rails, and it affects Mongrel in exactly the same way that it affects WEBrick. Justin
On 3/4/06 7:14 AM, "Justin Forder" <justin@justinforder.me.uk> wrote:> Ben Munat wrote: >> Eric Hodel wrote: >>> On Feb 27, 2006, at 9:55 PM, Ben Munat wrote: >>>> So what about the mythical "mutex on each request" that WEBrick has? >>> >>> I don''t know about Rails, but no such thing exists in WEBrick. (Note >>> that I''m not using WEBrick to serve Rails requests, I''m using it for >>> "image hits".) >> >> Duh... helps if I read more carefully. The passage in AWDWR is: [WEBrick >> is] not a particulary attractive approach for heavy-duty use. One of the >> reasons is the lack of thread safety in *ActionPack* (emphasis mine), >> which forces WEBrick to place a mutex at the gate of dynamic requests..." >> >> So, it is a problem in rails...... on the other hand, this is a rails >> list so I can see how I''d be thinking about that. :-) > > As I understand it, the mutex is in Rails, and it affects Mongrel in > exactly the same way that it affects WEBrick. >Yes, Mongrel has to use a "grand mutex" around the Dispatcher.dispatch in order to prevent Rails from going crazy. Rails just isn''t thread safe. One thing you can do in both Mongrel (and WEBrick) is if there''s a particular little part of your Rails application that needs to run very fast, then write a handler that runs right inside Mongrel. This then moves the processing out reducing the overhead and giving you full threaded operation (which you have to be careful of yourself). Zed A. Shaw http://www.zedshaw.com/
Zed Shaw wrote:>>>>On Feb 27, 2006, at 9:55 PM, Ben Munat wrote: >>>> >>>>>So what about the mythical "mutex on each request" that WEBrick has? >>>> >>>>I don''t know about Rails, but no such thing exists in WEBrick. (Note >>>>that I''m not using WEBrick to serve Rails requests, I''m using it for >>>>"image hits".) >>> >>>Duh... helps if I read more carefully. The passage in AWDWR is: [WEBrick >>>is] not a particulary attractive approach for heavy-duty use. One of the >>>reasons is the lack of thread safety in *ActionPack* (emphasis mine), >>>which forces WEBrick to place a mutex at the gate of dynamic requests..." >>> >> >>As I understand it, the mutex is in Rails, and it affects Mongrel in >>exactly the same way that it affects WEBrick. >> > > > Yes, Mongrel has to use a "grand mutex" around the Dispatcher.dispatch in > order to prevent Rails from going crazy. Rails just isn''t thread safe. > > One thing you can do in both Mongrel (and WEBrick) is if there''s a > particular little part of your Rails application that needs to run very > fast, then write a handler that runs right inside Mongrel. This then moves > the processing out reducing the overhead and giving you full threaded > operation (which you have to be careful of yourself).Wow. This just took the wind out of my sails. So, I should pretty much forget ever seeing a servlet container for rails? Sorry Zed, but this pretty much brings me around to Eric''s point of view: why bother creating Mongrel at all? b
On 3/4/06 1:04 PM, "Ben Munat" <bent@munat.com> wrote:> Zed Shaw wrote:>> Yes, Mongrel has to use a "grand mutex" around the Dispatcher.dispatch in >> order to prevent Rails from going crazy. Rails just isn''t thread safe. >> >> One thing you can do in both Mongrel (and WEBrick) is if there''s a >> particular little part of your Rails application that needs to run very >> fast, then write a handler that runs right inside Mongrel. This then moves >> the processing out reducing the overhead and giving you full threaded >> operation (which you have to be careful of yourself). > > Wow. This just took the wind out of my sails. > > So, I should pretty much forget ever seeing a servlet container for rails? > Sorry Zed, but > this pretty much brings me around to Eric''s point of view: why bother creating > Mongrel at all? >Well, first off, this threading issue is Rail''s problem, not Mongrel''s. Nitro and Camping don''t have this problem AFAIK. Second, Mongrel already is a "servlet container" for Ruby web applications. It has all the things you need to write your own web applications directly. In fact, that''s why it supports Nitro and Camping. The Nitro and Camping folks just grabbed Mongrel and wrote their own handlers to support their web framework. Take a look at the docs for: http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpHandler.html http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpResponse.html http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpServer.html See? Very much like your average "servlet container". The only real thing missing is the ability to load apps from gems or a directory (which is in the works as we speak). Now, as for why bother writing Mongrel (not sure if Eric really said that): Why bother writing Ruby? I mean, didn''t we already have C? For people who want the current best practice I say go with FastCGI. FastCGI however is a royal pain in the ass to manage (YMMV). The alternative way is to serve your applications directly using WEBrick. This gives you the advantage of the flexible simplicity of HTTP (think load balancers), but WEBrick is incredibly slow. Mongrel tries to be right in this niche: The speed of FastCGI with the simplicity of WEBrick for hosting. For many people the fact that Mongrel supports win32 just as well as POSIX systems is a big win. I''ve also heard other people like it for development since it''s quicker than WEBrick but just as easy to start. Other folks are using it to serve minor intranet sites directly since they don''t need to service a huge load but don''t want things slow for the few people they have. Finally, I''ve been working on a best practice document: http://mongrel.rubyforge.org/docs/lighttpd.html That will tell folks how to hook up a lighttpd+mongrel+memcache setup that should be competitive with the current crop of FastCGI configurations. Anyway, how else would I get to play with a Ragel HTTP parser and ternary search tries? :-) Zed A. Shaw http://www.zedshaw.com/
Thanks for the explanation Zed. I see that the threading issue is with Rails and not Mongrel and there''s not much you can do about that. That''s still frustrating, but well, I''ll just have to deal... or look into other Ruby web frameworks. I wish there was a bit more energy behind the Nitro effort... more docs would be nice. And actually, even with more docs I just don''t see them having the same level of crunchy-goodness as Rails any time soon. Oh, and for the record, I may have misrepresented what Eric said... he said "I don''t see what benefit Mongrel would give me" but really he was simply talking about speed at serving images... nothing involving thread issues, ease of app deployment, running multiple apps, or any other points that I would consider pertinent to the servlet container topic. b Zed Shaw wrote:> > > On 3/4/06 1:04 PM, "Ben Munat" <bent@munat.com> wrote: > > >>Zed Shaw wrote: > > >>>Yes, Mongrel has to use a "grand mutex" around the Dispatcher.dispatch in >>>order to prevent Rails from going crazy. Rails just isn''t thread safe. >>> >>>One thing you can do in both Mongrel (and WEBrick) is if there''s a >>>particular little part of your Rails application that needs to run very >>>fast, then write a handler that runs right inside Mongrel. This then moves >>>the processing out reducing the overhead and giving you full threaded >>>operation (which you have to be careful of yourself). >> >>Wow. This just took the wind out of my sails. >> >>So, I should pretty much forget ever seeing a servlet container for rails? >>Sorry Zed, but >>this pretty much brings me around to Eric''s point of view: why bother creating >>Mongrel at all? >> > > > Well, first off, this threading issue is Rail''s problem, not Mongrel''s. > Nitro and Camping don''t have this problem AFAIK. > > Second, Mongrel already is a "servlet container" for Ruby web applications. > It has all the things you need to write your own web applications directly. > In fact, that''s why it supports Nitro and Camping. The Nitro and Camping > folks just grabbed Mongrel and wrote their own handlers to support their web > framework. > > Take a look at the docs for: > > http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpHandler.html > http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html > http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpResponse.html > http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpServer.html > > See? Very much like your average "servlet container". The only real thing > missing is the ability to load apps from gems or a directory (which is in > the works as we speak). > > > Now, as for why bother writing Mongrel (not sure if Eric really said that): > > Why bother writing Ruby? I mean, didn''t we already have C? > > For people who want the current best practice I say go with FastCGI. > FastCGI however is a royal pain in the ass to manage (YMMV). The > alternative way is to serve your applications directly using WEBrick. This > gives you the advantage of the flexible simplicity of HTTP (think load > balancers), but WEBrick is incredibly slow. > > Mongrel tries to be right in this niche: The speed of FastCGI with the > simplicity of WEBrick for hosting. For many people the fact that Mongrel > supports win32 just as well as POSIX systems is a big win. I''ve also heard > other people like it for development since it''s quicker than WEBrick but > just as easy to start. Other folks are using it to serve minor intranet > sites directly since they don''t need to service a huge load but don''t want > things slow for the few people they have. > > Finally, I''ve been working on a best practice document: > > http://mongrel.rubyforge.org/docs/lighttpd.html > > That will tell folks how to hook up a lighttpd+mongrel+memcache setup that > should be competitive with the current crop of FastCGI configurations. > > Anyway, how else would I get to play with a Ragel HTTP parser and ternary > search tries? :-) > > > Zed A. Shaw > http://www.zedshaw.com/ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Sat, 2006-03-04 at 12:23 -0800, Ben Munat wrote:> the same level of > crunchy-goodness as Rails---- aren''t there enough train/rails metaphors to handle these things that we now have to add breakfast cereals to the mix? ;-) Craig
I wonder if anyone would clarify what is meant by the assertion that ActionPack is not thread-safe. A comment in the Rails source seems to indicate otherwise. I have not read enough of the source myself to understand what all of the issue are. //root/trunk/actionpack/lib/action_controller/base.rb lines 257-261> # Controls whether the application is thread-safe, so multi-threaded servers like WEBrick know whether to apply a mutex > # around the performance of each action. Action Pack and Active Record are by default > thread-safe, but many applications > # may not be. Turned off by default. > @@allow_concurrency = false > cattr_accessor :allow_concurrency-- John-Mason Shackelford Software Developer Pearson Educational Measurement 2510 North Dodge St. Iowa City, IA 52245 ph. 319-354-9200x6214 john-mason.shackelford@pearson.com http://pearsonedmeasurement.com