Hi Rails people, I just release Ruby/Event 0.4 and included in this release is a super high performance and easy to use SCGI server for running your snazzy Ruby On Rails applications. SCGI is an alternative to the current FCGI way of running your Ruby On Rails applications in production. The source distribution of Ruby/Event includes an scgi_rails script which will let you easily start, stop, and get status of your Rails apps. It also supports easily kicking up a bunch of children to service lots and lots of requests, but without requiring you to reconfigure your lighttpd server at all. Simply stop the current servers, then restart with the desired number of active children. I would really like people to try running their applications and report back to me how they work. There are known issues with Apache that I''m trying to resolve, but it works great with lighttpd and is fast as hell. Please pick it up at: http://www.zedshaw.com/projects/ruby_event/index.html And read the SCGI documentation at: http://www.zedshaw.com/projects/ruby_event/scgi_howto.html You''ll need to have the cmdparse gem (or library) installed to get it all to work correctly. Make sure you gem install cmdparse (2.0 version) before you try to use the scgi_rails script. Thanks! Zed A. Shaw http://www.zedshaw.com/
Cool! Could this work with IIS on windows? -L On 8/29/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:> > Hi Rails people, > > I just release Ruby/Event 0.4 and included in this release is a super high > performance and easy to use SCGI server for running your snazzy Ruby On > Rails applications. SCGI is an alternative to the current FCGI way of > running your Ruby On Rails applications in production. The source > distribution of Ruby/Event includes an scgi_rails script which will let you > easily start, stop, and get status of your Rails apps. > > It also supports easily kicking up a bunch of children to service lots and > lots of requests, but without requiring you to reconfigure your lighttpd > server at all. Simply stop the current servers, then restart with the > desired number of active children. > > I would really like people to try running their applications and report > back to me how they work. There are known issues with Apache that I''m trying > to resolve, but it works great with lighttpd and is fast as hell. > > Please pick it up at: > > http://www.zedshaw.com/projects/ruby_event/index.html > > And read the SCGI documentation at: > > http://www.zedshaw.com/projects/ruby_event/scgi_howto.html > > You''ll need to have the cmdparse gem (or library) installed to get it all > to work correctly. Make sure you gem install cmdparse (2.0 version) before > you try to use the scgi_rails script. > > Thanks! > > Zed A. Shaw > http://www.zedshaw.com/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Best Regards, -Larry "Work, work, work...there is no satisfactory alternative." --- E.Taft Benson _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Do you plan to get this running on Windows? Just curious because I only have Windows at work. Also, have you spoken to lighty''s author about the odd 404 dispatcher issue? It really is a buzz-kill for what would otherwise be an awesome option for those who struggle with FastCGI. Keep it up! And thanks! Web server implementation and scaling is the weakest part of Rails right now with FastCGI, mod_ruby, and Webrick. Perhaps SCGI will put it over the top. Zed A. Shaw wrote:> Hi Rails people, > > I just release Ruby/Event 0.4 and included in this release is a super high performance and easy to use SCGI server for running your snazzy Ruby On Rails applications. SCGI is an alternative to the current FCGI way of running your Ruby On Rails applications in production. The source distribution of Ruby/Event includes an scgi_rails script which will let you easily start, stop, and get status of your Rails apps. > > It also supports easily kicking up a bunch of children to service lots and lots of requests, but without requiring you to reconfigure your lighttpd server at all. Simply stop the current servers, then restart with the desired number of active children. > > I would really like people to try running their applications and report back to me how they work. There are known issues with Apache that I''m trying to resolve, but it works great with lighttpd and is fast as hell. > > Please pick it up at: > > http://www.zedshaw.com/projects/ruby_event/index.html > > And read the SCGI documentation at: > > http://www.zedshaw.com/projects/ruby_event/scgi_howto.html > > You''ll need to have the cmdparse gem (or library) installed to get it all to work correctly. Make sure you gem install cmdparse (2.0 version) before you try to use the scgi_rails script. > > Thanks! > > Zed A. Shaw > http://www.zedshaw.com/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
In article <20050829032634.176d4511.zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>, zedshaw- dd7LMGGEL7NBDgjK7y7TUQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> SCGI is an alternative to the current FCGI way of running your Ruby On Rails applications in production.Question: I realize that SCGI is meant to be easier to implement than FCGI. But given that ROR, Apache, and lighthttpd already support FCGI, what is the advantage, now or in the future, of switching to SCGI? It doesn''t seem that it claims any performance increase over FCGI... -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
according to what zed wrote a couple features. 1. ror and lighttpd already support scgi. apache is fashionable late..... AGAIN (apache was rather very late with fcgi so bragging about it does nothing) 2. fastcgi is a dormant project which everyone is skeptical about. 3. so far zed''s scgi implementation looks a LOT easier to handle. unless im just a retard i didnt know fcgi allowed you to start/kill processes on the fly as he mentioned as well get a status of what all the current processes are doing. and if its not a performance increate at least its a project that is still being worked on and performance increases are very well possible, though f/scgi really doesnt do that much work besides manage ruby processes and throw requests to those processes. its the stuff like fcgi (open source, dormant, no support) that scares corporate entities. you going to pay for something you know people use and can get support, use a free open source project that has been worked on for a long time has a nice userbase and a large developer base such as apache, or some open source project that someone worked on for a year on college or some sort and now hasent been touched in a long while. one of the first two! On 8/30/05, Jay Levitt <jay-news-WxwZQdyI2t0@public.gmane.org> wrote:> In article <20050829032634.176d4511.zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>, zedshaw- > dd7LMGGEL7NBDgjK7y7TUQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says... > > SCGI is an alternative to the current FCGI way of running your Ruby On Rails applications in production. > > Question: I realize that SCGI is meant to be easier to implement than > FCGI. But given that ROR, Apache, and lighthttpd already support FCGI, > what is the advantage, now or in the future, of switching to SCGI? It > doesn''t seem that it claims any performance increase over FCGI... > > -- > Jay Levitt | > Wellesley, MA | I feel calm. I feel ready. I can only > Faster: jay at jay dot fm | conclude that''s because I don''t have a > http://www.jay.fm | full grasp of the situation. - Mark Adler > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
In article <ab86ae0905090112172bdd622-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, zacheryph- Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> 1. ror and lighttpd already support scgi. apache is fashionable > late..... AGAIN (apache was rather very late with fcgi so bragging > about it does nothing) > 2. fastcgi is a dormant project which everyone is skeptical about. > 3. so far zed''s scgi implementation looks a LOT easier to handle. > unless im just a retard i didnt know fcgi allowed you to start/kill > processes on the fly as he mentioned as well get a status of what all > the current processes are doing. > > and if its not a performance increate at least its a project that is > still being worked on and performance increases are very well > possible, though f/scgi really doesnt do that much work besides manage > ruby processes and throw requests to those processes.Thanks... that makes sense. Sounds like SCGI is apparently more controllable and monitorable, which is certainly important, and more likely to get fixed if/when something breaks in the future. Both good reasons. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler