Hello Folks,
This is a quick announce of the 0.3 version of the SCGI Rails Runner
(now called SRR). SRR is a small project to create a simple single
script to run Ruby On Rails applications under the SCGI protocol. It
is intended as a compelling replacement for FastCGI in production.
This release is a complete clean-up rewrite that adds more features
while simplifying and reducing the code. The new code is much nicer,
sports a slight performance boost from previous versions. There''s also
reports that it runs in win32 under Apache+mod_scgi which I''ll be
reporting on more officially in a later release.
Go to http://www.zedshaw.com/projects/scgi_rails/ to get the goods.
=== Features ==
* Same performance as FastCGI and better performance than other
methods.
* Is a single cross-platform Ruby script that even runs on win32
(with some restrictions).
* Works with SCGI modules for Apache, Apache2, and Lighttpd
webservers.
* Simple to install, run, and configure.
* Supports simplified clustering on most POSIX systems for that
extra boost in concurrency.
* Gives out great status information to help manage your Rails
application’s resources.
* Makes it easy to manage your production deployment, and you can
even run your application in development mode exactly the same way for
extra testing efficiency.
* It can throttle connections to reduce the load on the server.
* You can set a maximum concurrent connections limit, which causes
any connections over the limit to see a special “BUSY” message. This
can help keep your site alive under heavy load.
* Simple to configure with your web server. Even if you use
clustering you’ll be able to manage your webserver and Rails
application independently.
* Reasonable defaults for almost everything based on user feedback.
* Completely free code licensed under Ruby’s own license.
=== Examples ==
You install it by copying one scgi_rails script to your Rails script
directory. From there you can just run it like all the other Rails
scripts. ***It requires the cmdparse gem to work.***
Once it''s installed you can start an application for testing with:
script/scgi_rails start -D
And run it in production mode with:
script/scgi_rails start -e production -D
And you can then start it with 3 children running concurrently on the
single 127.0.0.1:9999 port with:
script/scgi_rails start -e production -c 3
You can also start children with throttling and max concurrent
connections:
script/scgi_rails start -e production -m 10 -t 20 -c 3
Which basically says, "Start 3 children (-c) that will give a BUSY
message when the concurrent connections is over three (-m) and only
allow 20 connections/second (-t)."
Once you''ve got your children running, you can do:
script/scgi_rails status
And each child will dump this information into your /tmp directory:
http://www.zedshaw.com/projects/scgi_rails/sample_status.txt
Yep, that''s YAML, so feel free to do some Rails magic to make a nice
status page.
Finally, you stop all the children using:
script/scgi_rails stop
And that''s all.
=== CGI + SCGI Integration ==
The SCGI source distribution at
http://www.mems-exchange.org/software/scgi/ contains a CGI program that
will run against your SCGI server. You''ll have to edit a #define at
the top, but otherwise it works great. This is for people who have web
servers without SCGI support.
Hi Zed, It would be great if it could be made compatible with the file upload progress helper. I tried lighttpd 1.4.4 and SRR 0.3, but had no luck. (Note that lighttpd 1.4.4 also fails me when using fast_cgi with file upload progress). The only combination that works for me is Apache w/ fast_cgi. I''d love to have a more ways of doing that and SCGI is high on my list, especially for production and easy-to-setup development environments that resemble production closely. Thomas Am 18.09.2005 um 20:25 schrieb Zed A. Shaw:> Hello Folks, > > This is a quick announce of the 0.3 version of the SCGI Rails Runner > (now called SRR). SRR is a small project to create a simple single > script to run Ruby On Rails applications under the SCGI protocol. It > is intended as a compelling replacement for FastCGI in production. > > This release is a complete clean-up rewrite that adds more features > while simplifying and reducing the code. The new code is much nicer, > sports a slight performance boost from previous versions. There''s > also > reports that it runs in win32 under Apache+mod_scgi which I''ll be > reporting on more officially in a later release.
From the FAQ... SCGI Rails Runner FAQ Coming soon. People need to ask me questions though. :-; Ok, so I''ve got a few questions: I''m looking to handle my deployments w/ SwitchTower, so I''ll be implementing the tasks to use scgi_rails rather than spawner/spinner/reaper. Which leads me to... 1. Has anyone done this yet? Any tips? 2. Is there a way to do a nice reload? Ie., when deploying a new version of the application, I''d rather not shutdown all children immediately and then bring new ones up against the new app. To avoid the resulting downtime (even if it''s just a few seconds) of the app, I''d rather tell the children to exit when they''re done w/ their current request, and bring up a new set of children to respond to new requests.
I haven''t worked with switchtower yet. But, your second question is my planned "valving" feature, where it handles all remaining connections, shows a BUSY message to new connections, and then shutsdown when all the current ones are handled. I''ll see if I can work it up and make it for the next release. Zed A. Shaw http://www.zedshaw.com/ On Sun, 18 Sep 2005 14:17:36 -0700 Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> Ok, so I''ve got a few questions: I''m looking to handle my deployments > w/ SwitchTower, so I''ll be implementing the tasks to use scgi_rails > rather than spawner/spinner/reaper. Which leads me to... > > 1. Has anyone done this yet? Any tips? > > 2. Is there a way to do a nice reload? Ie., when deploying a new > version of the application, I''d rather not shutdown all children > immediately and then bring new ones up against the new app. To avoid > the resulting downtime (even if it''s just a few seconds) of the app, > I''d rather tell the children to exit when they''re done w/ their > current request, and bring up a new set of children to respond to new > requests. >
Any ideas what might be causing the failure? I''d try it with the Apache or Apache2 mod_scgi and see if the problem is with lighttpd. If SCGI works with Apache but not lighttpd then I can try to see how I might be able to work around it in lighttpd. Zed A. Shaw http://www.zedshaw.com/ On Sun, 18 Sep 2005 23:09:57 +0200 Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote:> Hi Zed, > > It would be great if it could be made compatible with the file > upload progress helper. >
I''ll see if I can test this with Apache 1.3 mod_scgi. Thomas Am 19.09.2005 um 02:16 schrieb Zed A. Shaw:> Any ideas what might be causing the failure? I''d try it with the > Apache or Apache2 mod_scgi and see if the problem is with > lighttpd. If > SCGI works with Apache but not lighttpd then I can try to see how I > might be able to work around it in lighttpd. > > Zed A. Shaw > http://www.zedshaw.com/ > > On Sun, 18 Sep 2005 23:09:57 +0200 > Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote: > > >> Hi Zed, >> >> It would be great if it could be made compatible with the file >> upload progress helper. >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
It doesn''t work with Apache 1.3+mod_scgi 1.7 either. I have the feeling that the whole request is buffered before it even reaches the rails app, instead of getting streamed to it. Thomas Am 19.09.2005 um 02:16 schrieb Zed A. Shaw:> Any ideas what might be causing the failure? I''d try it with the > Apache or Apache2 mod_scgi and see if the problem is with > lighttpd. If > SCGI works with Apache but not lighttpd then I can try to see how I > might be able to work around it in lighttpd. > > Zed A. Shaw > http://www.zedshaw.com/ > > On Sun, 18 Sep 2005 23:09:57 +0200 > Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote: > > >> Hi Zed, >> >> It would be great if it could be made compatible with the file >> upload progress helper. >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 9/19/05, Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote:> > It doesn''t work with Apache 1.3+mod_scgi 1.7 either. > > I have the feeling that the whole request is buffered before it > even reaches the rails app, instead of getting streamed to it.I''m not sure what, exactly, the problem is, but its probably not a buffering problem. mod_scgi excplicitly turns off such buffering. Curt Thomas> > Am 19.09.2005 um 02:16 schrieb Zed A. Shaw: > > > Any ideas what might be causing the failure? I''d try it with the > > Apache or Apache2 mod_scgi and see if the problem is with > > lighttpd. If > > SCGI works with Apache but not lighttpd then I can try to see how I > > might be able to work around it in lighttpd. > > > > Zed A. Shaw > > http://www.zedshaw.com/ > > > > On Sun, 18 Sep 2005 23:09:57 +0200 > > Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote: > > > > > >> Hi Zed, > >> > >> It would be great if it could be made compatible with the file > >> upload progress helper. > >> > >> > > _______________________________________________ > > 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 >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 18/09/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> From the FAQ... > > SCGI Rails Runner FAQ > Coming soon. People need to ask me questions though.Here''s a couple more, does anyone have an example httpd.conf for apache and SRR working together they could share? Reading the HOWTO for lighttpd it looks like the pattern is to set Apache to serve up /public from the application and then deal with any 404s with despatch.scgi which is actually the SCGI server. I tried the equivalent in apache with not much success: DocumentRoot /var/www/rails/public/ ErrorDocument 404 /despatch.scgi SCGIMount /despatch.scgi 127.0.0.1:9999 I got back a routing error: Recognition failed for "/despatch.scgi" Do I need strong mod_rewrite foo to get this working? Or does Apache require a different approach? Paul.
I used something like for testing:
<VirtualHost *:80>
Servername localhost
DocumentRoot /path/to/rails/app/public
SCGIMount /dispatch.scgi 127.0.0.1:9999
<Directory /path/to/rails/app/public>
AllowOverride All
</Directory>
</VirtualHost>
And changed the /path/to/rails/app/public/.htaccess file:
RewriteRule ^(.*)$ dispatch.scgi [QSA,L]
Thomas
Am 21.09.2005 um 12:26 schrieb Paul Wright:
> On 18/09/05, Michael Schoen
<schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:
>
>> From the FAQ...
>>
>> SCGI Rails Runner FAQ
>> Coming soon. People need to ask me questions though.
>>
>
> Here''s a couple more, does anyone have an example httpd.conf for
> apache and SRR working together they could share?
>
> Reading the HOWTO for lighttpd it looks like the pattern is to set
> Apache to serve up /public from the application and then deal with any
> 404s with despatch.scgi which is actually the SCGI server.
>
> I tried the equivalent in apache with not much success:
>
> DocumentRoot /var/www/rails/public/
> ErrorDocument 404 /despatch.scgi
> SCGIMount /despatch.scgi 127.0.0.1:9999
>
> I got back a routing error: Recognition failed for
"/despatch.scgi"
>
> Do I need strong mod_rewrite foo to get this working? Or does Apache
> require a different approach?
>
> Paul.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
On 21.9.2005, at 13.26, Paul Wright wrote:> On 18/09/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > >> From the FAQ... >> >> SCGI Rails Runner FAQ >> Coming soon. People need to ask me questions though. >> > > Here''s a couple more, does anyone have an example httpd.conf for > apache and SRR working together they could share? > > Reading the HOWTO for lighttpd it looks like the pattern is to set > Apache to serve up /public from the application and then deal with any > 404s with despatch.scgi which is actually the SCGI server. > > I tried the equivalent in apache with not much success: > > DocumentRoot /var/www/rails/public/ > ErrorDocument 404 /despatch.scgi > SCGIMount /despatch.scgi 127.0.0.1:9999 > > I got back a routing error: Recognition failed for "/despatch.scgi"The name of the script is dispatch.scgi, maybe that''s why apache can''t find it. //jarkko> > Do I need strong mod_rewrite foo to get this working? Or does Apache > require a different approach? > > Paul. > _______________________________________________ > 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 21.9.2005, at 14.13, Jarkko Laine wrote:> > On 21.9.2005, at 13.26, Paul Wright wrote: > > >> On 18/09/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: >> > > The name of the script is dispatch.scgi, maybe that''s why apache > can''t find it.Come to think of it, maybe not: NOTE: You do not need to create a public/dispatch.scgi file. This "file" is purely virtual in this configuration.> > //jarkko > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 21/09/05, Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote:> I used something like for testing: > > <VirtualHost *:80> > Servername localhost > DocumentRoot /path/to/rails/app/public > SCGIMount /dispatch.scgi 127.0.0.1:9999 > <Directory /path/to/rails/app/public> > AllowOverride All > </Directory> > </VirtualHost> > > And changed the /path/to/rails/app/public/.htaccess file: > RewriteRule ^(.*)$ dispatch.scgi [QSA,L] >Thanks for that Thomas, alas I still get back a routing error: Recognition failed for "/dispatch.scgi" Just to be clear: In the config files I''m now using dispatch.scgi instead of despatch.scgi and there is no actual file called dispatch.scgi in the public directory. The error I''m getting is a rails error: Action Controller: Exception caught. It looks like the actual url I''m requesting http://example.com/admin/view_return/59 isn''t being passed to SRR and instead it''s receiving the name of the error handler, dispatch.scgi. Could there be something extra I need to include in the configuration for Apache 2 that isn''t required for 1.3? I''ve used the above <VirtualHost> snippet as the base for my httpd.conf file both that and my .htaccess file are included below: ===httpd.conf==<VirtualHost 192.168.0.103:80> ServerName example.com:80 ServerAdmin paul.wright-hcDgGtZH8xNBDgjK7y7TUQ@public.gmane.org ServerSignature Off DocumentRoot /var/www/rails/public/ ErrorLog /var/log/httpd/error_log CustomLog "/var/log/httpd/access_log" combined SCGIMount /dispatch.scgi 127.0.0.1:9999 <Directory /var/www/rails/public/> AllowOverride All </Directory> </VirtualHost> ===.htaccess==AddHandler fastcgi-script .fcgi AddHandler cgi-script .cgi Options +FollowSymLinks +ExecCGI RewriteEngine On RewriteRule ^$ index.html [QSA] RewriteRule ^([^.]+)$ $1.html [QSA] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ dispatch.scgi [QSA,L] ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"
Possibly, my config was for 1.3. No idea on that one, though. Thomas Am 21.09.2005 um 13:43 schrieb Paul Wright:> Thanks for that Thomas, alas I still get back a routing error: > > Recognition failed for "/dispatch.scgi" > > Just to be clear: In the config files I''m now using dispatch.scgi > instead of despatch.scgi and there is no actual file called > dispatch.scgi in the public directory. The error I''m getting is a > rails error: Action Controller: Exception caught. It looks like the > actual url I''m requesting http://example.com/admin/view_return/59 > isn''t being passed to SRR and instead it''s receiving the name of the > error handler, dispatch.scgi. Could there be something extra I need > to include in the configuration for Apache 2 that isn''t required for > 1.3?
Hi, I''m working up a full set of docs tonight to cover the following: 1) Apache 2 config on POSIX type systems. 2) Curt Hibbs code on win32 plus Apache config for that system. 3) Configs for lighttpd to do the clustering. 4) FAQ for questions I''ve received so far. 5) Win32 specific docs. Please send me any other documentation requests. In the meantime, people on Debian should check out: http://www.jkraemer.net/ For a really good write-up using Apache2 with threads and scgi. I''ll be stealing heavily from this doc (thanks jkraemer). Zed On Wed, 21 Sep 2005 11:26:38 +0100 Paul Wright <wrighty-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 18/09/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > > From the FAQ... > > > > SCGI Rails Runner FAQ > > Coming soon. People need to ask me questions though. > > Here''s a couple more, does anyone have an example httpd.conf for > apache and SRR working together they could share? > > Reading the HOWTO for lighttpd it looks like the pattern is to set > Apache to serve up /public from the application and then deal with any > 404s with despatch.scgi which is actually the SCGI server. > > I tried the equivalent in apache with not much success: > > DocumentRoot /var/www/rails/public/ > ErrorDocument 404 /despatch.scgi > SCGIMount /despatch.scgi 127.0.0.1:9999 > > I got back a routing error: Recognition failed for "/despatch.scgi" > > Do I need strong mod_rewrite foo to get this working? Or does Apache > require a different approach? > > Paul. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 22.9.2005, at 3.53, Zed A. Shaw wrote:> > Please send me any other documentation requests. >How does (or will) it play together with the new spawner and reaper scripts? Will there be versions of them that work with the slightly different approach scgi is taking to listener processes? //jarkko> > In the meantime, people on Debian should check out: > > http://www.jkraemer.net/ > > For a really good write-up using Apache2 with threads and scgi. > > I''ll be stealing heavily from this doc (thanks jkraemer). > > Zed > > On Wed, 21 Sep 2005 11:26:38 +0100 > Paul Wright <wrighty-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > >> On 18/09/05, Michael Schoen <schoenm-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: >> >> >>> From the FAQ... >>> >>> SCGI Rails Runner FAQ >>> Coming soon. People need to ask me questions though. >>> >>> >> >> Here''s a couple more, does anyone have an example httpd.conf for >> apache and SRR working together they could share? >> >> Reading the HOWTO for lighttpd it looks like the pattern is to set >> Apache to serve up /public from the application and then deal with >> any >> 404s with despatch.scgi which is actually the SCGI server. >> >> I tried the equivalent in apache with not much success: >> >> DocumentRoot /var/www/rails/public/ >> ErrorDocument 404 /despatch.scgi >> SCGIMount /despatch.scgi 127.0.0.1:9999 >> >> I got back a routing error: Recognition failed for "/despatch.scgi" >> >> Do I need strong mod_rewrite foo to get this working? Or does Apache >> require a different approach? >> >> Paul. >> _______________________________________________ >> 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 > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Thanks for that pointer[1] Zed, I''ve got it running on Fedora 3 now with that example. I''m just a little unhappy that every request will go through to rails unless it has a period in it - it just feels a little flaky. Can anyone think of a better way of separating out the requests into filesystem and rails piles? The original .htaccess did some rewriting if the request didn''t exist on the filesystem - is it possible to use that to decide whether or not to turn off SCGIHandler? The real reason this is an issue is because with the one line SCGIMount / 127.0.0.1:9999 configuration every request is piped through rails which means that prototype.js and effects.js will never get served up. Which kind of breaks all the AJAX toys. (Although of course if you don''t use static files at all then it''s all you need.) Thanks again for the runner, it certainly looks to be one of the simplest ways of putting rails into production. [1] - http://www.jkraemer.net/