I see that lighttpd 1.3.14 supports SCGI. lighttpd 1.3.14 - 2005-06-15 18:10 Changes ------- * added SCGI support via mod_scgi * added hash-based and round-robin load balancing to mod_proxy * fixed range requests larger than 2Gb * fixed compilation on Solaris * fixed endless loops in mod_fastcgi, mod_cgi and mod_proxy * fixed handling of URIs for ''+'' and characters > 127 Has anyone tried to do a port of SCGI to Ruby? http://www.mems-exchange.org/software/scgi/ """ Introduction The SCGI protocol is a replacement for the Common Gateway Interface (CGI) protocol. It is a standard for applications to interface with HTTP servers. It is similar to FastCGI but is designed to be easier to implement. """ It has both Apache 1 & 2 implementations and now lighttpd. Might be an easier and more maintainable route than FastCGI. The developers of SCGI reported a small performance improvement when switching from FastCGI. Jimmie Houchin
On 6/18/05, Jimmie Houchin <jhouchin-frDgtZTyRT6sTnJN9+BGXg@public.gmane.org> wrote:> The SCGI protocol is a replacement for the Common Gateway Interface > (CGI) protocol. It is a standard for applications to interface with HTTP > servers. It is similar to FastCGI but is designed to be easier to implement.This is a really vague description, and the website for it doesn''t seem to contain anything else. Can you describe it in further detail? It sounds interesting (anything that offeres better performance than FastCGI while being easier to set up is interesting to me). -- Urban Artography http://artography.ath.cx
Rob Park wrote:> On 6/18/05, Jimmie Houchin <jhouchin-frDgtZTyRT6sTnJN9+BGXg@public.gmane.org> wrote: > >>The SCGI protocol is a replacement for the Common Gateway Interface >>(CGI) protocol. It is a standard for applications to interface with HTTP >>servers. It is similar to FastCGI but is designed to be easier to implement. > > > This is a really vague description, and the website for it doesn''t > seem to contain anything else. Can you describe it in further detail? > It sounds interesting (anything that offeres better performance than > FastCGI while being easier to set up is interesting to me).Unfortunately I''m not able to help much. The only thing I know is that on the mailing list for Quixote, a python web app framework, they reported a performance boost by switching to SCGI. They are the developers of SCGI and I don''t even know if they still formally support FCGI after switching. The quixote mailing list would be quite helpful in answering any questions. They are a friendly bunch. You can access that list via gmane if you prefer. You can also look at their archives off the web. http://www.mems-exchange.org/software/quixote/ archives at: http://mail.mems-exchange.org/pipermail/quixote-users/ or at gmane: http://dir.gmane.org/gmane.comp.web.quixote.user Hope this helps. I just thought it might benefit Rails if it could use SCGI. Especially now that the favored http server supports it. Jimmie
On 6/18/05, Jimmie Houchin <jhouchin-frDgtZTyRT6sTnJN9+BGXg@public.gmane.org> wrote:> Unfortunately I''m not able to help much. The only thing I know is that > on the mailing list for Quixote, a python web app framework, they > reported a performance boost by switching to SCGI. They are the > developers of SCGI and I don''t even know if they still formally support > FCGI after switching.Well, the performance gains reported are marginal (they were saying like 5%).> or at gmane: http://dir.gmane.org/gmane.comp.web.quixote.userLooked over the archives a bit, didn''t find any information that was terribly exciting. I''d really like to know what it is that SCGI *does*, what makes it faster than FCGI.> I just thought it might benefit Rails if it could use SCGI. > Especially now that the favored http server supports it.By all means, implement an SCGI interface to rails. Maybe then you can explain how SCGI works ;) Choice is good, and if SCGI really is better, then it will win out in the end. I know from experience that FCGI is really fiddly to set up properly, so something that''s faster and easier to set up would be a welcome change, especially for the rails crowd. I''ve always thought of FCGI as being kinda opposing the rails mentality of "everything is super easy to set up". -- Urban Artography http://artography.ath.cx
According the the Quixote website (http://quixote.ca) "FastCGI employs a similar architecture [to SCGI], but the FastCGI protocol''s greater complexity makes it less reliable." and also that is is much simpler to set up "SCGI isn''t much more difficult to configure [than regular CGI]" On 19 Jun 2005, at 07:55, Rob Park wrote:> On 6/18/05, Jimmie Houchin <jhouchin-frDgtZTyRT6sTnJN9+BGXg@public.gmane.org> wrote: > >> Unfortunately I''m not able to help much. The only thing I know is >> that >> on the mailing list for Quixote, a python web app framework, they >> reported a performance boost by switching to SCGI. They are the >> developers of SCGI and I don''t even know if they still formally >> support >> FCGI after switching. >> > > Well, the performance gains reported are marginal (they were saying > like 5%). > > >> or at gmane: http://dir.gmane.org/gmane.comp.web.quixote.user >> > > Looked over the archives a bit, didn''t find any information that was > terribly exciting. I''d really like to know what it is that SCGI > *does*, what makes it faster than FCGI. > > >> I just thought it might benefit Rails if it could use SCGI. >> Especially now that the favored http server supports it. >> > > By all means, implement an SCGI interface to rails. Maybe then you can > explain how SCGI works ;) > > Choice is good, and if SCGI really is better, then it will win out in > the end. I know from experience that FCGI is really fiddly to set up > properly, so something that''s faster and easier to set up would be a > welcome change, especially for the rails crowd. I''ve always thought of > FCGI as being kinda opposing the rails mentality of "everything is > super easy to set up". > > -- > Urban Artography > http://artography.ath.cx > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 19-jun-2005, at 8:55, Rob Park wrote:> On 6/18/05, Jimmie Houchin <jhouchin-frDgtZTyRT6sTnJN9+BGXg@public.gmane.org> wrote: > > Choice is good, and if SCGI really is better, then it will win out in > the end. I know from experience that FCGI is really fiddly to set up > properly, so something that''s faster and easier to set up would be a > welcome change, especially for the rails crowd. I''ve always thought of > FCGI as being kinda opposing the rails mentality of "everything is > super easy to set up".This might sound vague, but after switching from PHP to Rails the only thing I came to heavily miss is, well, mod_php and a good bytecode accelerator. After all this infrastructure was (and is, as I see it) the biggest strength of PHP, how ugly it might be. Hope that once we will have something comparable for Ruby (but supposedly not before YARV comes out. Trying out mod_ruby I was very pleased (much more pleased that with lighttpd and FCGI). -- Julian "Julik" Tarkhanov
On Sat, 2005-06-18 at 14:10 -0500, Jimmie Houchin wrote:> I see that lighttpd 1.3.14 supports SCGI. ><snip>> > Has anyone tried to do a port of SCGI to Ruby?<snip> I''m actually in the process of doing a wrapper for libevent in Ruby similar to my recent Ruby/Odeum. I''m mostly writing it as a means of doing a tutorial on writing C extensions. One thing I''m missing is a practical use of the libevent as an example. After fighting with FCGI for a couple days I''m now considering doing an SCGI adapter as the example. If you''re willing to help on it then I''d be more than grateful. I''m hoping that using libevent and the framework I''m planning will make the SCGI implementation fast as all hell, but that remains to be seen really. Anyway, hit me off-list if you''re interested in working on this together. I''m thinking I could write the libevent and tutorial, and then you and I can beta-test the libevent binding by writing an SCGI implementation. What do you think? Zed A. Shaw http://www.zedshaw.com/
Zed A. Shaw wrote:> On Sat, 2005-06-18 at 14:10 -0500, Jimmie Houchin wrote: > >>I see that lighttpd 1.3.14 supports SCGI. > > <snip> > >>Has anyone tried to do a port of SCGI to Ruby? > > <snip> > > I''m actually in the process of doing a wrapper for libevent in Ruby > similar to my recent Ruby/Odeum. I''m mostly writing it as a means of > doing a tutorial on writing C extensions. One thing I''m missing is a > practical use of the libevent as an example. After fighting with FCGI > for a couple days I''m now considering doing an SCGI adapter as the > example. > > If you''re willing to help on it then I''d be more than grateful. I''m > hoping that using libevent and the framework I''m planning will make the > SCGI implementation fast as all hell, but that remains to be seen > really. > > Anyway, hit me off-list if you''re interested in working on this > together. I''m thinking I could write the libevent and tutorial, and > then you and I can beta-test the libevent binding by writing an SCGI > implementation. What do you think?Oh I wish I could help. But I am just a fellow learning on the side. I am not a professional developer. I currently am reading the Pickaxe 2 book, and have just ordered the Rails book. I have no C or low level skills. I have spent a lot of time playing with Python and with Squeak, but Ruby is new to me. I just recently started reading this list again and I saw issues with FCGI. I know a year or so ago when I was playing around trying to setup FCGI it wasn''t fun. So I thought anything that had the potential to reduce maintainance and pickup a little performance is good deal. I would be happy to try out, beta test what comes down the pike when I get Rails setup on my machine. I am running Ubuntu on a dual Opteron server. Your ideas above sound pretty sweet. I hope it goes as well as you see it in your head. :) Jimmie
> Hope that once we will have something comparable for Ruby (but > supposedly not before YARV comes out. Trying out mod_ruby I was very > pleased (much more pleased that with lighttpd and FCGI).Ditto - in the end, no matter how much people say PHP is crap, etc - (which the language _is_) - it''s extremely well packaged and integrated with apache. I would like to see rails be as easy to deply as my old PHP apps. It has a long way to go. I haven''t had to tinker around with a PHP install in a long time. Debian packages for it just _work_, no fuss, no "try testing out your fcgi install and tuning it to avoid 500 errors etc". Reliability before neato-features ;) _a -- alex black, founder the turing studio, inc. 510.666.0074 root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org http://www.turingstudio.com 2600 10th street, suite 635 berkeley, ca 94710
On 21-jun-2005, at 21:04, alex black wrote:>> Hope that once we will have something comparable for Ruby (but >> supposedly not before YARV comes out. Trying out mod_ruby I was >> very pleased (much more pleased that with lighttpd and FCGI). >> > > Ditto - > > Reliability before neato-features ;)This is not about reliability, this is about maturity and design decisions. Let''s see what we got now on the scene: 1) mod_php (the one you know inside-out), which: a) is always loaded into Apache b) but always loads the scripts for every request and destroys them when the processing is done On the bright side you have the fact that thousands of people and sites use it every day, in any kind of perverse hsoting situation 2) mod_perl a) is always loaded into apache b) classes and namespaces are shared meaning that the scripts stay loaded into memory all the time the server process is active 3) mod_ruby ditto for mod_ruby - it is a carbon copy of mod_perl 4) fastcgi instances have to be started up with the server, the control that the server has over instances is weak - meaning that sometimes the communication between the server and the application goes bonkers (and you get 500 response etc.) The problem here is that: a) there is no shared-nothing (REALLY shared-nothing) module for Ruby and Apache b) There is no way to cache the compiled Rails application (this is where things like ionCube and ZerndOptimizer help a bunch) between requests - when the "shared nothing" environment has to be SHUT DOWN. The whole stability and security of PHP stems from the fact that the whole interpreter sandbox is recycled between requests, so nithing can go wrong (well, ok - sometimes you write spiffy scripts that segfault Apache because you didn''t free some C resource). It is very pity that there is no shared-nothing Apache module for Ruby and it is very pity that there is no bytecode cache. They both helped to raise PHP to it''s paramount (i.e. you can get complex without even thinking about the environment because you know all will get killed on next request). The scenario I would love to see: a) mod_ruby whch works like mod_php (every request is sandboxed from others including the namespace). b) loading Rails is expensive (especially minding all the evals), so I would love to have my Rails app bytecode-cached and just engaged when a request comes in. c) having your app recycled between requests. Then people on shared wouldn''t have to think about keeping too much eye on runaway processes or other crap of that nature, the admins would be happy (because the app is not persisted between requests - and thus cannot leak memory etc.) and I would sleep better at night. The thing is - when David made Rails this infrastructure WAS NOT THERE. And it still isn''t there, and we will all have to wait 1 year or more before such solutions start to appear. Even more - noone will go and just make this kind of thing now (when the Ruby VM is about to change). How I take it - let''s see how it works out. For now the pleasure of developing with Ruby and rails outweights the disastrous pain of hosting it. But I hope it''s not going to be like this forever. -- Julian "Julik" Tarkhanov