I''ve seen several postings where FastCGI is being used with RoR projects, yet, most of the material I''ve read (Dave Thomas'' book, online articles, etc) recommend not using FastCGI anymore because it is a dormant project and hasn''t been updated since 2003 (I think???). So, I went out and got Simple CGI instead. It had to be compiled and installed from source on my Suse boxes, but it works just fine and had the advantage of also working just fine on my XP notebook. Is there a reason folks are using FastCGI over Simple CGI? -- Posted via http://www.ruby-forum.com/.
Hello Cody...>From what I understand its related to when SCGI became production readywhich was only few months ago.. I have feeling that ASF''s renewed interest in the mod-fcgi code that people will be using both for awhie with big improvements in obht as they competee with another.. But like You I am choosing SCGI although I still pratice deploying to both to keep my knowledge of both current.. Cody Skidmore wrote:> I''ve seen several postings where FastCGI is being used with RoR > projects, yet, most of the material I''ve read (Dave Thomas'' book, online > articles, etc) recommend not using FastCGI anymore because it is a > dormant project and hasn''t been updated since 2003 (I think???). > > So, I went out and got Simple CGI instead. It had to be compiled and > installed from source on my Suse boxes, but it works just fine and had > the advantage of also working just fine on my XP notebook. > > Is there a reason folks are using FastCGI over Simple CGI?-- Posted via http://www.ruby-forum.com/.
Cody Skidmore wrote:> I''ve seen several postings where FastCGI is being used with RoR > projects, yet, most of the material I''ve read (Dave Thomas'' book, online > articles, etc) recommend not using FastCGI anymore because it is a > dormant project and hasn''t been updated since 2003 (I think???).I''d be careful not to confuse the Apache mod_fcgi module (which was dormant at the time the AWD book was published, I think this has changed some recently) with the FastCGI module that comes as part of LightTPD. IMO, LightTPD is the premier production deployment solution for Rails apps, today. Obviously, that could change in the future, but I''ve been using it for the past 6 months and it''s been outstanding for deploying my Rails apps under OS X Server (but should work equally well for any *nix system).> So, I went out and got Simple CGI instead. It had to be compiled and > installed from source on my Suse boxes, but it works just fine and had > the advantage of also working just fine on my XP notebook. > > Is there a reason folks are using FastCGI over Simple CGI?With FastCGI behind LightTPD, there''s a compiled Ruby module that works really well. I also believe it makes things faster, overall, and more memory efficient. This is not the case with SCGI. The Ruby SCGI Runner, by Zed Shaw, is normal Ruby code, which is less efficient for Unix-based systems. I don''t really know the situation for Windows-based deployment, since that''s not something I''ve ever had to look into... -Brian
I''m using SCGI behind Apache on windows, and used memcached demand on linux server, but i do not know how much the memory efficient. 2006/3/3, Brian V. Hughes <brianvh@alum.dartmouth.org>:> > Cody Skidmore wrote: > > I''ve seen several postings where FastCGI is being used with RoR > > projects, yet, most of the material I''ve read (Dave Thomas'' book, online > > articles, etc) recommend not using FastCGI anymore because it is a > > dormant project and hasn''t been updated since 2003 (I think???). > > I''d be careful not to confuse the Apache mod_fcgi module (which was > dormant at > the time the AWD book was published, I think this has changed some > recently) > with the FastCGI module that comes as part of LightTPD. IMO, LightTPD is > the > premier production deployment solution for Rails apps, today. > > Obviously, that could change in the future, but I''ve been using it for the > past > 6 months and it''s been outstanding for deploying my Rails apps under OS X > Server > (but should work equally well for any *nix system). > > > So, I went out and got Simple CGI instead. It had to be compiled and > > installed from source on my Suse boxes, but it works just fine and had > > the advantage of also working just fine on my XP notebook. > > > > Is there a reason folks are using FastCGI over Simple CGI? > > With FastCGI behind LightTPD, there''s a compiled Ruby module that works > really > well. I also believe it makes things faster, overall, and more memory > efficient. > This is not the case with SCGI. The Ruby SCGI Runner, by Zed Shaw, is > normal > Ruby code, which is less efficient for Unix-based systems. I don''t really > know > the situation for Windows-based deployment, since that''s not something > I''ve ever > had to look into... > > -Brian > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Best Regards, Caiwangqin http://www.uuzone.com Mobile: +8613951787088 Tel: +86025-84818086 ext 233 Fax: +86025-84814993 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060303/00aa46bf/attachment-0001.html
Brian V. Hughes wrote:> I''d be careful not to confuse the Apache mod_fcgi module (which was > dormant at the time the AWD book was published, I think this has > changed some recently) with the FastCGI module that comes as part > of LightTPD. IMO, LightTPD is the premier production deployment > solution for Rails apps, today. >In response to: "I''d be careful not to confuse the Apache mod_fcgi module (which was dormant at the time the AWD book was published,"... There is no Apache module named "mod_fcgi". There are 2 released FastCGI modules for Apache and one that is upcoming: * mod_fastcgi for Apache 1.x/2.0 - version 2.4.2 released in Nov 2003 and last snapshot distribution is April 2004. * mod_fcgid for Apache 2.x - version 1.08 released in Jan 2006 and has always been actively maintained (so this cannot be the dormant "mod_fcgi" you mentioned). * mod_proxy_fcgi for Apache which is new and not even released yet In response to: "IMO, LightTPD is the premier production deployment> solution for Rails apps, today"...I''ve been using Lighttpd on an internal test server and I can say that Lighttpd-1.4.10 (latest stable version) is not as stable as Apache. Lighttpd-1.4.10 has massive memory leaks and other stability problems which are well-documented at: * http://trac.lighttpd.net/trac/wiki/Release-1.4.10-bugs * http://forum.lighttpd.net/forum/1 In terms of performance, people should be aware that benchmark comparison between Lighttpd and Apache 2 is with MPM-Prefork. Note that Apache''s MPM-Prefork makes Apache 2 perform as badly as Apache 1. One reason someone might use MPM-Prefork for benchmarking Apache 2.x is to make sure they have the slowest possible performance to make their product shine. If you look at the source of the benchmark, it is a commercial webserver vendor trying to emphasize their performance advantage. To avoid getting fooled, I encourage you to do your own benchmarks instead of falling victom to hype. Use ab or seige on a separate physical machine to benchmark your server software. You''ll see results vastly different from biased benchmarks posted online by people trying to push their products on the public. One last issue to consider is that Lighttpd does not (yet) have mod_security which can prevent XSS and SQL injection attacks and more. Given the stability/memory-leak problems, lack of compelling speed advantage over Apache 2 MPM-Worker, and lack of mod_security, I really don''t see how Lighttpd can be considered the "premier production deployment solution for Rails apps, today." Believe me, I''d be one of the first to use Lighttpd in production if it performed better than Apache 2 but it just isn''t ready for prime-time yet. In the meantime, I''ve submitted several Lighttpd bug reports and suggested the use of splint (which the author said he''d investigate) so I''m doing my part to help Lighttpd catch up to Apache''s robustness. The worst we can do is pretend it is better or even on par with Apache today by ignoring reality. -- Posted via http://www.ruby-forum.com/.
I don''t use lighttpd personally, but several people have downgraded from 1.4.10 to 1.4.9 and reported that it''s a stable setup. Apparently 1.4.10 is a "bad" release, but 1.4.9 was "good" (from a Rails perspective). Search the mailing list archives for details Regards Dave M. On 03/03/06, Rich A. <usrlocalinfo@yahoo.com> wrote:> Brian V. Hughes wrote: > > > I''d be careful not to confuse the Apache mod_fcgi module (which was > > dormant at the time the AWD book was published, I think this has > > changed some recently) with the FastCGI module that comes as part > > of LightTPD. IMO, LightTPD is the premier production deployment > > solution for Rails apps, today. > > > > In response to: "I''d be careful not to confuse the Apache mod_fcgi > module (which was dormant at the time the AWD book was published,"... > > There is no Apache module named "mod_fcgi". There are 2 released > FastCGI modules for Apache and one that is upcoming: > > * mod_fastcgi for Apache 1.x/2.0 - version 2.4.2 released in Nov 2003 > and last snapshot distribution is April 2004. > > * mod_fcgid for Apache 2.x - version 1.08 released in Jan 2006 and has > always been actively maintained (so this cannot be the dormant > "mod_fcgi" you mentioned). > > * mod_proxy_fcgi for Apache which is new and not even released yet > > In response to: "IMO, LightTPD is the premier production deployment > > solution for Rails apps, today"... > > I''ve been using Lighttpd on an internal test server and I can say that > Lighttpd-1.4.10 (latest stable version) is not as stable as Apache. > Lighttpd-1.4.10 has massive memory leaks and other stability problems > which are well-documented at: > > * http://trac.lighttpd.net/trac/wiki/Release-1.4.10-bugs > * http://forum.lighttpd.net/forum/1 > > In terms of performance, people should be aware that benchmark > comparison between Lighttpd and Apache 2 is with MPM-Prefork. Note that > Apache''s MPM-Prefork makes Apache 2 perform as badly as Apache 1. One > reason someone might use MPM-Prefork for benchmarking Apache 2.x is to > make sure they have the slowest possible performance to make their > product shine. If you look at the source of the benchmark, it is a > commercial webserver vendor trying to emphasize their performance > advantage. > > To avoid getting fooled, I encourage you to do your own benchmarks > instead of falling victom to hype. Use ab or seige on a separate > physical machine to benchmark your server software. You''ll see results > vastly different from biased benchmarks posted online by people trying > to push their products on the public. > > One last issue to consider is that Lighttpd does not (yet) have > mod_security which can prevent XSS and SQL injection attacks and more. > > Given the stability/memory-leak problems, lack of compelling speed > advantage over Apache 2 MPM-Worker, and lack of mod_security, I really > don''t see how Lighttpd can be considered the "premier production > deployment solution for Rails apps, today." > > Believe me, I''d be one of the first to use Lighttpd in production if it > performed better than Apache 2 but it just isn''t ready for prime-time > yet. In the meantime, I''ve submitted several Lighttpd bug reports and > suggested the use of splint (which the author said he''d investigate) so > I''m doing my part to help Lighttpd catch up to Apache''s robustness. The > worst we can do is pretend it is better or even on par with Apache today > by ignoring reality. > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Is it still true that with SCGI and Apache, you can only have a single handler since mod_scgi isn?t smart enough to split the load? That was a killer for us with Apache+SCGI (lighty doesn?t have this problem). From: Jesse Cai <jesse.cai@gmail.com> Reply-To: <rails@lists.rubyonrails.org> Date: Fri, 3 Mar 2006 10:21:00 +0800 To: <rails@lists.rubyonrails.org> Subject: Re: [Rails] FastCGI vs. Simple CGI I''m using SCGI behind Apache on windows, and used memcached demand on linux server, but i do not know how much the memory efficient. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060303/4c921f33/attachment.html
David Mitchell wrote:> I don''t use lighttpd personally, but several people have downgraded > from 1.4.10 to 1.4.9 and reported that it''s a stable setup. > Apparently 1.4.10 is a "bad" release, but 1.4.9 was "good" (from a > Rails perspective). > > Search the mailing list archives for details > > Regards > > Dave M.A patched version of Lighttpd-1.4.10 is working more reliably for me than 1.4.9. I hope more people would give Lighttpd-1.4.10+ in svn a try so that 1.4.11 can be the most stable release ever. If using the latest from svn, be aware that the changes in revision 1009 are incomplete for mod_fastcgi.c and mod_scgi.c. The change to those files need to happen in 2 places but was only done once. And if using the old Lighttpd-1.4.9, be aware of these issues: * #203 virtual hosting (evhost) domains are not case insensitive * #470 mod_cgi is not accepting valid responses * #480 mod_fastcgi is only using 1 fastcgi-host for load-balancing * #492 False Content-Length on some 30x redirects * #493 server.modules is unpopulated on startup * #495 can''t use $HTTP["remoteip"] inside $HTTP["url"] * #502 mod_ssi ignores assigned mime type * #505 Complete header variable matching * #509 rejects IPv4 connects with server.use-ipv6 * #510 allows one connection, then shuts down * #552 CGI process zombies if request isn''t read * #554 Fix for CGI / Zombie issue in ticket # 552 For now, I think it is more prudent to run Apache 2.0.55 with mod_fcgid and mod_security. But I''m very optimistic that Lighttpd will finally become ready for prime-time this summer (or even sooner). By "prime-time", I mean stable & secure enough to run ecommerce websites that people can use for their sole income. Also, if the only reason you''re using Lighttpd is because you were led to believe it is much faster than Apache 2.x, then do your own benchmark using Apache 2.0.55 MPM-Worker (not MPM-Prefork)--be sure to be sitting down before reading the results because you''ll be surprised at which is faster. -- Posted via http://www.ruby-forum.com/.
Rich A. wrote:> > For now, I think it is more prudent to run Apache 2.0.55 with mod_fcgid > and mod_security. >Thanks to everyone for responding. This information will change the direction I''m headed in. -- Posted via http://www.ruby-forum.com/.
Rich A. wrote:> David Mitchell wrote: >> I don''t use lighttpd personally, but several people have downgraded >> from 1.4.10 to 1.4.9 and reported that it''s a stable setup. >> Apparently 1.4.10 is a "bad" release, but 1.4.9 was "good" (from a >> Rails perspective). >> >> Search the mailing list archives for details >> >> Regards >> >> Dave M. > > A patched version of Lighttpd-1.4.10 is working more reliably for me > than 1.4.9. I hope more people would give Lighttpd-1.4.10+ in svn a try > so that 1.4.11 can be the most stable release ever. > > If using the latest from svn, be aware that the changes in revision 1009 > are incomplete for mod_fastcgi.c and mod_scgi.c. The change to those > files need to happen in 2 places but was only done once. > > And if using the old Lighttpd-1.4.9, be aware of these issues: > > * #203 virtual hosting (evhost) domains are not case insensitive > * #470 mod_cgi is not accepting valid responses > * #480 mod_fastcgi is only using 1 fastcgi-host for load-balancing > * #492 False Content-Length on some 30x redirects > * #493 server.modules is unpopulated on startup > * #495 can''t use $HTTP["remoteip"] inside $HTTP["url"] > * #502 mod_ssi ignores assigned mime type > * #505 Complete header variable matching > * #509 rejects IPv4 connects with server.use-ipv6 > * #510 allows one connection, then shuts down > * #552 CGI process zombies if request isn''t read > * #554 Fix for CGI / Zombie issue in ticket # 552 > > For now, I think it is more prudent to run Apache 2.0.55 with mod_fcgid > and mod_security. > > But I''m very optimistic that Lighttpd will finally become ready for > prime-time this summer (or even sooner). By "prime-time", I mean stable > & secure enough to run ecommerce websites that people can use for their > sole income. > > Also, if the only reason you''re using Lighttpd is because you were led > to believe it is much faster than Apache 2.x, then do your own benchmark > using Apache 2.0.55 MPM-Worker (not MPM-Prefork)--be sure to be sitting > down before reading the results because you''ll be surprised at which is > faster.Have you published your preferred configuration of Apache 2.0.55/MPM-Worker/mod_fcgid/Rails? It sounds as if this would be extremely useful to people working in corporate environments with tight controls on infrastructure, particularly where the chosen server platform is Windows. thanks very much for the advice Justin