Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Rails on SCGI and Lighttpd

Posted by Sun, 26 Feb 2006 14:23:00 GMT

5 comments Latest by dgibbons Fri, 03 Mar 2006 17:14:04 GMT

Just recently, we began testing out SCGI with Lighttpd. We were running into weird problems with FCGI and both Apache and Lighttpd… things like fcgi processes that would get spawned and just hang around after the apache or lighttpd processes were killed. We have a few cron scripts that try to play cleanup… but that isn’t a long-term solution.

So, we took the plunge on a few client projects for their demos and I am happy to report that it took maybe 15 minutes to read the documentation and get things going.

I have a new friend and scgi_ctrl is it’s name.

It’s only a matter of time before we work on an rbot plugin so that we can reload our applications via IRC. :-)

Get help with your Rails project

comments powered by Disqus
Comments

Leave a response

  1. Avatar
    øyvinds Sun, 26 Feb 2006 22:16:19 GMT

    seem to remember that you cant use it with unix sockets? Is there any performance penalty for using tcp/ip?

    ö

  2. Avatar
    Ilya Mon, 27 Feb 2006 05:43:26 GMT

    Hi!

    I also did one SCGI+Lighttpd installation and it seems to be very simple to start this configuration.

    Is there SwitchTower support for this cofiguration?

    Ilya

  3. Avatar
    Damien Tanner Mon, 27 Feb 2006 15:37:29 GMT

    Glad to hear some scgi success.

  4. Avatar
    eliott Thu, 02 Mar 2006 23:08:12 GMT

    hmmm.. Interesting. I will have to give it a shot. It would be nice to reload my rails app without having to restart the webserver (ala fcgi+lighttpd).

  5. Avatar
    dgibbons Fri, 03 Mar 2006 17:14:04 GMT

    I’ve still noticed some occations when you have to restart the entire webserver not just the scgi process. So it’s still kind of hit or miss on that part.

    However being able to specifically restart processes via rdb makes much easier to write a script to restart only one site rather then the killall -9 that I see with fastcgi that wipes out all the sites you have running.

    As far as speed concerns of tcp/ip to sockets, I can’t imagine there would be many. Most people are using tcp/ip for their database already and it’s on the local system, so the loopback interface is rarely seen as the slowdown in something like this.

    Having to manage Yet Another Port is kinda an annoyance but not much worse then having a seperate postgresql instance for each customer.