What exactly are the downsides to running a rails app through WEBrick? We write web accessible bioinformatics software and I was pondering a switch to Rails (already using it for my own work). The problem is, we try to release most of our software as open source and encourage other universities and research institutions to use it. We want the widest possible audience and saying, "yes, our software is great, but to use it you''ll have to install ruby, rails, fastCGI, lighttpd and then figure out how to get them all configured together" isn''t going to cut it. Most of our audience is already familiar (and using) PHP, so to make the switch we need to be able to ensure that the end user will be able to get it up and running with a minimum of hastle. Bearing in mind that our applications typically only have one user at a time, could WEBrick be a feasible alternative to lighttpd/fastCGI? Thanks, Mike
On 6/3/05, Mike Evans <mje113-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> What exactly are the downsides to running a rails app through WEBrick?Serious memory leaks,I have read numerous time about them on this list.> Most of our audience is already familiar (and using) PHP, so to make > the switch we need to be able to ensure that the end user will be able > to get it up and running with a minimum of hastle.If the audience is already familiar with PHP, chances are that they also use apache and mod_php. If so, using mod_ruby shouldn''t be too diffult. I think the requirements are about the same for both (anyone car to confirm please ?): - php, mod_php, yourapp - ruby, mod_ruby, rails, your_app the only difference being rails, that is, if your previous php apps didn''t use php packages ... jean> Bearing in mind that our applications typically only have one user at > a time, could WEBrick be a feasible alternative to lighttpd/fastCGI? > Thanks, > Mike > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
* Mike Evans (mje113-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050603 13:40]:> We want the widest possible audience and saying, "yes, our software is > great, but to use it you''ll have to install ruby, rails, fastCGI, > lighttpd and then figure out how to get them all configured together" > isn''t going to cut it.(I run all my Rails applications using FCGI under Apache, if that helps (it probably helps a tiny bit since PHP users are often Apache users). You don''t have to move away from a large web server if it''s already installed and available.) There is going to be some level of installation that has to be carried out moving to a different platform, though part of the problem, I''m guessing, is really the *different* installation. Setting up PHP + Apache + Mysql (or whichever) + virtual hosts + libraries + application software is a royal pain in the butt. However, many users have gotten familiar with the steps involved and consider it straightforward now. To run a Ruby application Ruby is going to have to be installed. To run a PHP application PHP is going to have to be installed. To run a Rails application Rails will have to be installed. To run most PHP applications, some PHP support libraries or frameworks (probably at least PEAR if not some other components) are going to have to be installed. To run an application, the application is going to have to be installed. To run a PHP application, a web server is going to have to be installed and configured. To run a Ruby application, something listening on the web port is going to have to be installed. If you want database connectivity, whether in Ruby or PHP, the database and the necessary connectivity libraries are going to have to be installed. When it comes right down to it, PHP almost always requires as much or more support software as/than Rails does. The issue is primarily one of it being *different* stuff that you need for Rails than you already know about for PHP. As an historical aside, I''ve seen a lot of people refuse to deploy PHP applications (only singling PHP out because that''s the alternative under discussion) for many good reasons, but I frequently heard complaints about the amount of installation and configuration required on various OSs to get PHP applications up and running. I think that is mostly mitigated these days with the package management tools available on the modern OS, but it''s still a consideration (just as the installation dependencies for Rails are a consideration to you, hence the question). In the past I''ve played "chase the patches" with PHP. Every time another security problem was found in PHP I''d have to push an upgrade out to the various servers running PHP and then run tests on the applications to ensure they still worked (sometimes they didn''t.). With Rails at least the first part is typically easier (thanks to Ruby Gems), and the framework provides built in support for easy test writing, so that second phase *tends* to be easier..> Most of our audience is already familiar (and using) PHP, so to make > the switch we need to be able to ensure that the end user will be able > to get it up and running with a minimum of hastle.I haven''t checked in a while, but the Rails one-click installer for Windows was supposed to be pretty slick. Not sure that there''s been much in the way of progress on that front for other platforms. The steps on Unix-style systems could pretty much be automated. It''s quite easy in some places: "apt-get install rails" gets you at least halfway there under Debian, but there are still some headaches in getting fcgi happy -- still, not very many though (and all easily automatable).> Bearing in mind that our applications typically only have one user at > a time, could WEBrick be a feasible alternative to lighttpd/fastCGI?Yes, it could, and there''s not really much risk in deploying a Rails app on webrick and later moving to fcgi (for example) -- in the sense that you only have to change how the .htaccess dispatches the application. You''ll have to assess the risk inherent in getting your user base on a webrick Rails app and then not being able to move away from Rails if/when you decide you must force your userbase to install fcgi, etc. I.e., do you have to decide now? Only you can answer that question though. Webrick is going to be slower than fastcgi (but faster than cgi) and pretty much confine you to a single-threaded style of behavior. This doesn''t mean the application wouldn''t support multiple users, just that concurrent requests are an issue. Rick -- http://www.rickbradley.com MUPRN: 383 | the worst. Matt is the random email haiku | guy''s name... last name escapes | me at the moment.
Mike Evans wrote:>Bearing in mind that our applications typically only have one user at >a time, could WEBrick be a feasible alternative to lighttpd/fastCGI? > >Yes if you find it a feasible alternative. You''ll have to test it under normal user conditions and check that it doesn''t eat all memory. For internal applications I think webrick is a good enough platform. You should restart webrick application daily. If others are familiar with Apache + mod_php, then you can also deploy rails with Apache + mod_ruby. I think that is another alternative to lighttpd/fastCGI. - Adam
* Rick Bradley [2005-06-03 15:06]:> When it comes right down to it, PHP almost always requires as much or > more support software as/than Rails does. The issue is primarily one of > it being *different* stuff that you need for Rails than you already know > about for PHP.Eh, I think this is a bit off. Apache and PHP are configured "out of the box" on nearly all [standard] linux/bsd installs or hosting plans these days, and easily managed with apt or rpm. So for many sites, apache/php are often just "part of the server". The same can''t be said for FastCGI or Ruby/Rails (yet, hopefully). And you can use PHP''s built-in mysql bindings if you have to as well. All that said, Rails certainly isn''t a huge hurdle. But to say it''s [nearly] as easy or easier than PHP at this point I don''t feel is quite accurate. Especially as a big determining factor for "easy" or doable is how familiar the current administrator of a system is with everything - in this, ruby/rails and fastcgi are way down the list compared to basic apache/php. -- ________________________________ toddgrimason*todd[ at ]slack.net
On 6/3/05, Adam Majer <adamm-+878OnfSgr5BDgjK7y7TUQ@public.gmane.org> wrote:> Yes if you find it a feasible alternative. You''ll have to test it under > normal user conditions and check that it doesn''t eat all memory. For > internal applications I think webrick is a good enough platform. You > should restart webrick application daily.Ok, that makes sense... a simple cron could perform the restart for me.> If others are familiar with Apache + mod_php, then you can also deploy > rails with Apache + mod_ruby. I think that is another alternative to > lighttpd/fastCGI. >I thought that there were issues with mod_ruby? Is that not the case?
On 6/3/05, Rick Bradley <rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org> wrote:> * Mike Evans (mje113-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050603 13:40]: > > We want the widest possible audience and saying, "yes, our software is > > great, but to use it you''ll have to install ruby, rails, fastCGI, > > lighttpd and then figure out how to get them all configured together" > > isn''t going to cut it. > > (I run all my Rails applications using FCGI under Apache, if that helps > (it probably helps a tiny bit since PHP users are often Apache users). > You don''t have to move away from a large web server if it''s already > installed and available.) >I hear what you''re saying and would agree with you on most points (that fastCGI / lighttpd isn''t a huge chore to set up), but in my world most projects are ultimately funded by grants which ultimately are coming from NSF or some other government agency. In their grant review process they have only recently become used to words like PHP and APACHE... it''s odd but they seem to be happier when they''re familiar with the *word*, not the technology (they''d rather we were using .NET / MSSQL). So, for Rails to fly (on grant projects) it''s gotta be easy to get up and running. m
Mike Evans wrote:>On 6/3/05, Adam Majer <adamm-+878OnfSgr5BDgjK7y7TUQ@public.gmane.org> wrote: > > >>If others are familiar with Apache + mod_php, then you can also deploy >>rails with Apache + mod_ruby. I think that is another alternative to >>lighttpd/fastCGI. >> >> >> > >I thought that there were issues with mod_ruby? Is that not the case? > >I don''t know. I''m still in development using webrick :P But for production I hope to use Apache and mod_ruby if possible. - Adam
On Jun 4, 2005, at 3:49, Todd Grimason wrote:> * Rick Bradley [2005-06-03 15:06]: > >> When it comes right down to it, PHP almost always requires as much or >> more support software as/than Rails does. The issue is primarily one >> of >> it being *different* stuff that you need for Rails than you already >> know >> about for PHP. > > Eh, I think this is a bit off. Apache and PHP are configured "out of > the > box" on nearly all [standard] linux/bsd installs or hosting plans these > days, and easily managed with apt or rpm. So for many sites, apache/php > are often just "part of the server". The same can''t be said for FastCGI > or Ruby/Rails (yet, hopefully). And you can use PHP''s built-in mysql > bindings if you have to as well.I want to *strongly* agree here. On my OS X box, I can use a PHP app by plopping it in the right location and enabling "Personal Web Sharing" from the System preferences - clicking a checkbox, basically. That takes a complete novice who doesn''t know anything about unix maybe 3 minutes. On the other hand, our experienced web admin did have some trouble setting up FastCGI / configuring Apache the right way for Rails. It took him in the range of hours, and I doubt Joe average user could do it at all. Would be nice to have some kind of standard install script that does it all... hmm... N. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> > Would be nice to have some kind of standard install script that does it > all...a one click installer was just released for tiger that sets up rails, gems, ruby, mysql, all via an installer package in one swoop. I had trouble installing rails the first time, but it is like riding a bike. After you install rails a few times, it becomes just another few clicks and actually very easy. An installer also exists for windows. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> > it''s gotta be easy to get up > and running.Rails is gaining popularity, and most recently its dreamhost who supports rails now via 1 click install from a web interface. Other large hosts will (hopefully) soon follow... When i first setup php it wasnt that easy, on par with a rails install. Now PHP is so popular that it is installed everywhere. If the oneclick installers are not easy enough, rails will hopefully be even easier to install as time goes on. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 3-jun-2005, at 22:51, Mike Evans wrote:> > I thought that there were issues with mod_ruby? Is that not the case?Works like a charm for me (but only with one application per Apache setup - that''s the problem with it, basically). The memory footprint is actually smaller that what FCGI instances consume, and feels quite a bit faster (faster than lighttpd_fcgi). The downside is also that you have to build it against the same includes/libs as your other modules - I wrote about it on the wiki. -- Julian "Julik" Tarkhanov
> >>If others are familiar with Apache + mod_php, then you can also deploy > >>rails with Apache + mod_ruby. I think that is another alternative to > >>lighttpd/fastCGI. > >> > >> > >> > > > >I thought that there were issues with mod_ruby? Is that not the case? > > > > > I don''t know. I''m still in development using webrick :P > > But for production I hope to use Apache and mod_ruby if possible.Its not. It will impose a 15-20 mb overhead per http helper ( 40-50 on a average visited site ) and restricts you to one rails application per server. Please stop suggesting mod_ruby once and for all. The mod_* are all flawed in their very concept. Fastcgi is the solution. -- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
On 19-jun-2005, at 16:11, Tobias Luetke wrote:>>>> If others are familiar with Apache + mod_php, then you can also >>>> deploy >>>> rails with Apache + mod_ruby. I think that is another >>>> alternative to >>>> lighttpd/fastCGI. >>> >> I don''t know. I''m still in development using webrick :P >> >> But for production I hope to use Apache and mod_ruby if possible. >> > > Its not. It will impose a 15-20 mb overhead per http helper ( 40-50 on > a average visited site ) and restricts you to one rails application > per server. > > Please stop suggesting mod_ruby once and for all. The mod_* are all > flawed in their very concept. Fastcgi is the solution.Tobi, it is of course very unpolite to argue with such an experienced Rails developer as you, but: a) I don''t like to do top on my server and see 60 Gawddamn rubies there (happened with FCGI, BOTH Apache and lighttpd) b) two of them hogging Gawddamn HALF of the system memory (happened with lighttpd, happening NOW to be precise) c) I expect my interpreters to be Gawddamn killed when the FCGI dispatcher process is killed (fails often with FCGI) d) I don''t see a difference in spending 20 MB of RAM for an HTTPD or a Ruby interpreter. In my testing my (moderate) Rails app never goes above 20-25 MB real within mod_ruby (in development), especially if I am running a Rails site on my apache e) starting up Apache with mod_ruby is (yes it is) faster than starting Apache (or lighttpd for that matter) with Ruby instances. f) I don''t expect dispatcher problems on my app which is in no way related to my own development or code (fastcgi;.crash.log anyone?) Or am I missing something here?? -- Julian "Julik" Tarkhanov
On 6/19/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Please stop suggesting mod_ruby once and for all. The mod_* are all > flawed in their very concept. Fastcgi is the solution.I agree. I tried mod_ruby and fastcgi, and fastcgi is considerably faster as far as I can tell. It would be helpful if a new rails project''s .htaccess file just defaulted to dispatch.fcgi. -- Greg Donald Zend Certified Engineer http://destiney.com/
Hm, I''m with Tobias on this one. First of all, you can restrict your fastcgi manager to spawn only limited amount of ruby processes. 60 processes sounds like too much. In our pretty much busy production system we have only 8 ruby processes servicing all incoming requests. Each ruby process takes about 10M of RAM. If we were running it with mod_ruby, each apache instances would gain this 10M extra for no apparent reason. Kent. On 6/19/05, Julian ''Julik'' Tarkhanov <listbox-RY+snkucC20@public.gmane.org> wrote:> > On 19-jun-2005, at 16:11, Tobias Luetke wrote: > > >>>> If others are familiar with Apache + mod_php, then you can also > >>>> deploy > >>>> rails with Apache + mod_ruby. I think that is another > >>>> alternative to > >>>> lighttpd/fastCGI. > >>> > >> I don''t know. I''m still in development using webrick :P > >> > >> But for production I hope to use Apache and mod_ruby if possible. > >> > > > > Its not. It will impose a 15-20 mb overhead per http helper ( 40-50 on > > a average visited site ) and restricts you to one rails application > > per server. > > > > Please stop suggesting mod_ruby once and for all. The mod_* are all > > flawed in their very concept. Fastcgi is the solution. > > Tobi, it is of course very unpolite to argue with such an experienced > Rails developer as you, but: > > a) I don''t like to do top on my server and see 60 Gawddamn rubies > there (happened with FCGI, BOTH Apache and lighttpd) > > b) two of them hogging Gawddamn HALF of the system memory (happened > with lighttpd, happening NOW to be precise) > > c) I expect my interpreters to be Gawddamn killed when the FCGI > dispatcher process is killed (fails often with FCGI) > > d) I don''t see a difference in spending 20 MB of RAM for an HTTPD or > a Ruby interpreter. In my testing my (moderate) Rails app never goes > above 20-25 MB real within mod_ruby (in development), especially if I > am running a Rails site on my apache > > e) starting up Apache with mod_ruby is (yes it is) faster than > starting Apache (or lighttpd for that matter) with Ruby instances. > > f) I don''t expect dispatcher problems on my app which is in no way > related to my own development or code (fastcgi;.crash.log anyone?) > > Or am I missing something here?? > > -- > Julian "Julik" Tarkhanov > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> Tobi, it is of course very unpolite to argue with such an experienced > Rails developer as you, but:Absolutely not!> > a) I don''t like to do top on my server and see 60 Gawddamn rubies > there (happened with FCGI, BOTH Apache and lighttpd)As others pointed out you can restrict the number of "handler" fcgi processes. I believe in Apache you can even set a global limit, both lower and upper.> > b) two of them hogging Gawddamn HALF of the system memory (happened > with lighttpd, happening NOW to be precise)Rails apps in development mode leak memory. Just set FcgiServerConfig --initial-env=production and enforce production mode for your server. In a hosting environment i''d also suggest to install some sort of supervisor tool which can remove process which go bonkers.> c) I expect my interpreters to be Gawddamn killed when the FCGI > dispatcher process is killed (fails often with FCGI)I never had this issue. But you can add killall ruby to your apache / lighttpd init.d script.> d) I don''t see a difference in spending 20 MB of RAM for an HTTPD or > a Ruby interpreter. In my testing my (moderate) Rails app never goes > above 20-25 MB real within mod_ruby (in development), especially if I > am running a Rails site on my apacheIt bugs me when a http process is starting a 10-20mb ruby application which only ever handles static images, javascripts or css.> e) starting up Apache with mod_ruby is (yes it is) faster than > starting Apache (or lighttpd for that matter) with Ruby instances.Right because the rails app is loaded upon first access. Same with fastcgi when you set the minimum to zero.> f) I don''t expect dispatcher problems on my app which is in no way > related to my own development or code (fastcgi;.crash.log anyone?)fastcgi.crash.log is misleading in name. The things you will find in there are stacktraces of when your server ended the pooled processes. This happens if there is not a lot of traffic and fcgi decides to downsize the pool or if you have any idle time outs set or a maximum of requests which can be handled per instance.> Or am I missing something here??Well... there is still the thing that you can only run 1 ruby application per server with mod_ruby. I''m still not sure how this isn''t an absolute KO in your situation. Another point you need to remember is that fcgi processes are not required to run on localhost. In fact you can have any number of machines behind your web server load balance your rails app.> > -- > Julian "Julik" Tarkhanov > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
On 19-jun-2005, at 23:15, Tobias Luetke wrote:>> >> a) I don''t like to do top on my server and see 60 Gawddamn rubies >> there (happened with FCGI, BOTH Apache and lighttpd) > As others pointed out you can restrict the number of "handler" fcgi > processes. I believe in Apache you can even set a global limit, both > lower and upper.Of course you can, both in lighttpd and mod_fcgi. The thing is it doesn''t work! It just doesn''t! On lighttpd it is not so prominent as on mod_fcgi, but still. What I mean by "doesn''t" is that it works for an hour and then not, and you get berserk rubies - and the longer the time the more. Granted, you can write a script that will retart the server/kill the ruby interpreters/whatnot but this is, ahem. Strange. The last 3 years I''ve been doing web-development my web-apps didn''t need any "killage" - the httpd spawning did the trick by itself. Maybe it just feels wrong to me.> > Rails apps in development mode leak memory. Just set FcgiServerConfig > --initial-env=production and enforce production mode for your server. > In a hosting environment i''d also suggest to install some sort of > supervisor tool which can remove process which go bonkers.Hmm, will try that. Strange how a ruby on one of my rails apps was able to leak 250MB in about 20 minutes - it''s not leaking, it'' drowning in blood :-)))> >> c) I expect my interpreters to be Gawddamn killed when the FCGI >> dispatcher process is killed (fails often with FCGI) > > I never had this issue. But you can add killall ruby to your apache / > lighttpd init.d script.That''s an option. Maybe asking that the stuff spawned by the webserver gets killed automatically is too much luxury indeed.> > >> d) I don''t see a difference in spending 20 MB of RAM for an HTTPD or >> a Ruby interpreter. In my testing my (moderate) Rails app never goes >> above 20-25 MB real within mod_ruby (in development), especially if I >> am running a Rails site on my apache > > It bugs me when a http process is starting a 10-20mb ruby application > which only ever handles static images, javascripts or css.I don''t think it does before you hit your dispatcher on that process. Then again, you can just recycle them more often.> >> e) starting up Apache with mod_ruby is (yes it is) faster than >> starting Apache (or lighttpd for that matter) with Ruby instances. > > Right because the rails app is loaded upon first access. Same with > fastcgi when you set the minimum to zero.Valid point, but starting FCGI without adaptive spawning (which doesn''t work reliably) is number_of_instances slower anyway :-)> > Well... there is still the thing that you can only run 1 ruby > application per server with mod_ruby. I''m still not sure how this > isn''t an absolute KO in your situation.I run my own stripped down Apache setup inside which only one ruby application is running. This has to do with the tricky way my app is deployed. As long as there''s one Rails app on this httpd (I don''t think there will be more) I will sleep much better knowing that none of that FCGI massacre is going on the shared server, especially when the admins decide to check the top. And I would be super-careful if I have to run Rails on other servers where FastCGI will be a requirement. FCGI stability is... an issue. Let''s face it. I''m not as experienced as others to call it "crap", for instance, but I don''t really feel myself on the safe side with it. Especially on shared. I would feel myself much better with a REAL shared-nothing module for ruby (mod_ruby_private anyone? :-) with a bytecode compiler as it is done with PHP. Especially on shared. Sorry for being harsh but what I found is - it''s just as painful to serve Rails apps as it is pleasant to develop them.> > Another point you need to remember is that fcgi processes are not > required to run on localhost. In fact you can have any number of > machines behind your web server load balance your rails app.This is indeed a cool feat, but in the coming year I doubt I will ever need it. The point I had - mod_ruby WORKS for Rails and it works for me, and I like the way it works more than FastCGI. Coming from PHP background I like it more (the fact that I configure my webserver and application services in one place). And I don''t think it''s nonsense to run the app in mod_ruby if some find it useful (especially after all the trouble with FCGI). -- Julian "Julik" Tarkhanov
We are running WEBrick in production mode on Win2003 Server and it works fine ... Memory usage is quite stable. I need to connect to SQL server, so Win32 was forced [because the SQL Server Adapter requires ADO], so I deployed with WEBrick 2 months ago, hoping that someone would simplify the apache/iis + fastcgi setup which was dodgy at the time. Anyhow, the deployment is currently stable and fast enough, so I havent needed to go the next step yet, but we do have low volume here. -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Mike Evans Sent: Saturday, 4 June 2005 4:33 AM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] downsides to WEBrick? What exactly are the downsides to running a rails app through WEBrick? We write web accessible bioinformatics software and I was pondering a switch to Rails (already using it for my own work). The problem is, we try to release most of our software as open source and encourage other universities and research institutions to use it. We want the widest possible audience and saying, "yes, our software is great, but to use it you''ll have to install ruby, rails, fastCGI, lighttpd and then figure out how to get them all configured together" isn''t going to cut it. Most of our audience is already familiar (and using) PHP, so to make the switch we need to be able to ensure that the end user will be able to get it up and running with a minimum of hastle. Bearing in mind that our applications typically only have one user at a time, could WEBrick be a feasible alternative to lighttpd/fastCGI? Thanks, Mike _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
>>> When it comes right down to it, PHP almost always requires as much or >>> more support software as/than Rails does. The issue is primarily one >>> of >>> it being *different* stuff that you need for Rails than you already >>> know >>> about for PHP.Dude, what color is the sky in your world? PHP and apache configuration is about as simple as it gets with mod_php, and it''s extremely stable. Rails is great, but the amount of good documentation on production configs with apache or lighttpd is small, and it''s nearly so well tested as PHP-fu. Also, there are SO many things I have to tweak that just don''t come up with PHP. At the moment, rails definitely loses on the "low barrier to entry" side - you have to do a lot of work to get a server config that will even render pages, much less a stable one that won''t periodically error 500 on you (like _all_ of my current apache configs do). I''m going to switch to lighttpd, but that''s not because I hate apache - it''s because there aren''t standard, stable configs for apache. If I''m wrong - wonderful - please point me to the URL of a site running some good traffic, and sanitized config files which run that site - then include those configs in all the rails docs ;) best, _alex
I have a small patch for WEBrick to make it multithreaded. Unfortunately it has taken me a while to set up a dev environment at home and my workplace forbids working on open source projects on their equiptment. I chose WEBrick because of the simplicity of installation and configuration. One of the main downsides I found withWEBrick is the single threaded-ness of the web server because of the use of the global $stdin and $stdout in the servlet that requires the mutex around all requests. I have subclassed CGI and added a few changes to pass through the output stream in other areas to get around this issue. If anyone else is interested I would be happy to spend a few hours on generalizing and merging the changes (I hacked out a version that may break the other modes of operation. Since I was only developing on WEBrick, this was sufficient). I may need some help testing the changes with FCGI, so any assistence would be appreciated. I think might make WEBrick an alternative for low volume sites. Cheers, Will Sobel
Hmm as far as I know webrick is multi threaded by default. Its just that the rails dispatcher puts in a big mutex around the request because ActionController isn''t. AC is simply not designed for multi threading because in fcgi and mod_ruby each worker runs in an own instance, this simplifies the code considerably. It would be extreamly cool if we could get AC to a state where we can get rid of the mutex but i''m not sure how to do that. On 6/19/05, willsobel-ee4meeAH724@public.gmane.org <willsobel-ee4meeAH724@public.gmane.org> wrote:> > I have a small patch for WEBrick to make it multithreaded. Unfortunately it has taken me a while to set up a dev environment at home and my workplace forbids working on open source projects on their equiptment.Crazy -- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
> Hmm as far as I know webrick is multi threaded by default. Its just > that the rails dispatcher puts in a big mutex around the request > because ActionController isn''t.Right, but AC should be fairly easy to make thread safe. Each request is already being handled by a new instance, so I think its just a few simple details holding back the thread support. And it would indeed speed up WEBrick considerably if it could loose the mutex. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
I''ll put some time into submitting a general patch. Hopefully this will make WEBrick a possibility for production. Will Sobel ----------------------------------> Hmm as far as I know webrick is multi threaded by default. Its just > that the rails dispatcher puts in a big mutex around the request > because ActionController isn''t.Right, but AC should be fairly easy to make thread safe. Each request is already being handled by a new instance, so I think its just a few simple details holding back the thread support. And it would indeed speed up WEBrick considerably if it could loose the mutex.