# Rails, FCGI, Dreamhost **URL:** \ **Category:** Rails\ **Created:** [April 20, 2006, 7:48pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348 "2006-04-20T19:48:29Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![al-evans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/54ee81/32.png) [@al-evans](https://www.ruby-forum.com/u/al-evans)\ **Post date:** [April 20, 2006, 7:48pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348/1 "2006-04-20T19:48:29Z")
Is anybody getting acceptable performance with a Rails application on Dreamhost? By this, I mean response times no greater than 3 seconds, and no large numbers of FCGI processes that you have to kill manually. If so, how? I’ve ended up running a constant ping script (once every ten minutes), and still have to kill some number of excess dispatch.fcgi processes every day. Along with this, I get somewhere between five and eight glitches a day – 500 errors and timeouts, mostly – as reported by the ping script (which barely touches the app, just makes sure it’s reponding) I suspect this is due to their use of dynamic FCGI allocation, along with what is probably a too-short timeout on the FCGI processes for Rails apps. From what I’ve found in searching the web, the only way this will work controllably is if they use Apache to proxy for my own lighttpd process running on a port other than 80, and let me control my own FCGI allocation. Does anybody have a different/better solution? If I don’t hear of one, I’ll post here when I submit this as a suggestion. I’ll appreciate it if you’d expend some of your valuable suggestion-voting credits to support me! I think this is the best chance to get reliable Rails application hosting at Dreamhost. –Al Evans ---
**Author:** ![al-evans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/54ee81/32.png) [@al-evans](https://www.ruby-forum.com/u/al-evans)\ **Post date:** [April 20, 2006, 8:13pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348/2 "2006-04-20T20:13:35Z")
Hope you are lucky and this doesn’t rocket you above their 60 cpu minutes per day policy. If so you’ll start getting warning emails from them to lower your usage, or else be moved to a different (presumably saturated) server (and all the downtime that move may take). I wish their was better shared hosting options out there. i.e. shared hosting with lighttpd, on a steady servers which don’t go down once a day, and somewhere near dreamhost bandwidth / storage levels… – Scott B. Web D. Electro Interactive > **[Electro Interactive - Web Development. Ruby on Rails. Web Standards.](http://www.electrointeractive.com)** > > Electro Interactive is a full service new media design and development company. ---
**Author:** ![al-evans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/54ee81/32.png) [@al-evans](https://www.ruby-forum.com/u/al-evans)\ **Post date:** [April 20, 2006, 8:16pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348/3 "2006-04-20T20:16:42Z")
And, my biggest solution to this so far is Page Caching. Pages come down instantly and don’t invoke Rails at all. Anything which can be cached, should be. It will make your apps much more performant. And you’ll avoid those errors, because Rails isn’t getting invoked. Of course this doesn’t work for all scenarios. There are ways to get this to work , even for sites which require login. I’ve gone to setting cookies when the user logs in and then using javascript to rewrite portions of the page. For example, show admin links, welcome back so-and-so, hide the login box, etc. For more ideas on this, see: [http://habtm.com/articles/2005/12/16/page-caching-your-whole-app](http://habtm.com/articles/2005/12/16/page-caching-your-whole-app) Thanks, – Scott B. Web D. Electro Interactive > **[Electro Interactive - Web Development. Ruby on Rails. Web Standards.](http://www.electrointeractive.com)** > > Electro Interactive is a full service new media design and development company. ---
**Author:** ![al-evans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/54ee81/32.png) [@al-evans](https://www.ruby-forum.com/u/al-evans)\ **Post date:** [April 20, 2006, 9:03pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348/4 "2006-04-20T21:03:12Z")
On Thursday 20 Apr 2006 19:15, Scott B. wrote: > And, my biggest solution to this so far is Page Caching. Pages come > down instantly and don’t invoke Rails at all. Anything which can be > cached, should be. It will make your apps much more performant. And > you’ll avoid those errors, because Rails isn’t getting invoked. Of > course this doesn’t work for all scenarios. It’s worth doing this even if you don’t _have_ to. 😉 ~Dave – Dave S. Rent-A-Monkey Website Development > **[Tree Removal Service For Home & Businesses in Salt Lake City, UT](https://www.rentamonkey.com/)** > > Rent A Monkey Tree Service provides the safest, highest-quality tree removal for Salt Lake City, UT homes and businesses. Request a service today! PGP Key: [http://www.rentamonkey.com/pgpkey.asc](http://www.rentamonkey.com/pgpkey.asc) ---
**Author:** ![al-evans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/54ee81/32.png) [@al-evans](https://www.ruby-forum.com/u/al-evans)\ **Post date:** [April 20, 2006, 8:59pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348/5 "2006-04-20T20:59:56Z")
On Thursday 20 Apr 2006 18:48, Al Evans wrote: > Is anybody getting acceptable performance with a Rails application on > Dreamhost? By this, I mean response times no greater than 3 seconds, and > no large numbers of FCGI processes that you have to kill manually. For sure. > If so, how? I just followed the quickstart guide from: [http://wiki.dreamhost.com/index.php/Ruby\_on\_Rails](http://wiki.dreamhost.com/index.php/Ruby_on_Rails) > I’ve ended up running a constant ping script (once every ten minutes), > and still have to kill some number of excess dispatch.fcgi processes > every day. ## I haven’t had to do this, but then I do make quite extensive use of page caching so a lot of the time the Rails app isn’t actually doing anything maybe that’s where my scenario differs from yours? So have you just got wget / curl or something sending one of your Rails pages to /dev/null every 10 minutes? Come to think of it, on an initial page load when nobody has touched the Rails app for a few days, I do get a short delay (2 seconds) while it starts up, but on subsequent requests to other non-cached paged it’s fast as anything. I guess the initial page load doesn’t bother me much, since probably some of it is down to a DNS lookup too. You shouldn’t be getting long delays on every page view though - I only get them when a (low usage, unfinished) site hasn’t been touched for a few days. I’ve found that with more than one FCGI handler per site, it seems to slow things down, not improve them. > Along with this, I get somewhere between five and eight glitches a day > – 500 errors and timeouts, mostly – as reported by the ping script > (which barely touches the app, just makes sure it’s reponding) I don’t get these. > I suspect this is due to their use of dynamic FCGI allocation, along > with what is probably a too-short timeout on the FCGI processes for > Rails apps. Have you added the stuff from step 5 of the quickstart guide, to prevent your FCGI from being killed off periodically? I’ve added it, and everything seems OK. I think I have had some weird thing with too many FCGI handlers running and causing a problem, but I just killed them all and it was OK again after that - can’t remember the exact details, though I think it was to do with Actionmailer. > > From what I’ve found in searching the web, the only way this will work > > controllably is if they use Apache to proxy for my own lighttpd process > running on a port other than 80, and let me control my own FCGI > allocation. > > Does anybody have a different/better solution? I didn’t know you could run Lighty on Dreamhost? Can anyone confirm, because if so I’d also quite like to do that. Also, with Textdrive you have to reserve a port number to do it on, so I would imagine Dreamhost would have to operate a similar policy. I wouldn’t go running it and using up ports without checking with them first. > If I don’t hear of one, I’ll post here when I submit this as a > suggestion. I’ll appreciate it if you’d expend some of your valuable > suggestion-voting credits to support me! I think this is the best chance > to get reliable Rails application hosting at Dreamhost. It has occurred to me that we Dreamhost Railers ought to keep in touch about things. It took me a while to get my first Rails app working on Dreamhost, but now I can put a Rails site live even easier than I used to put PHP sites live. Sorry to hear about your troubles though - I hope I’m not going to run into them as I put bigger and bigger Rails sites up on Dreamhost. Keep us posted, ~Dave – Dave S. Rent-A-Monkey Website Development > **[Tree Removal Service For Home & Businesses in Salt Lake City, UT](https://www.rentamonkey.com/)** > > Rent A Monkey Tree Service provides the safest, highest-quality tree removal for Salt Lake City, UT homes and businesses. Request a service today! PGP Key: [http://www.rentamonkey.com/pgpkey.asc](http://www.rentamonkey.com/pgpkey.asc) ---
**Author:** ![al-evans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/54ee81/32.png) [@al-evans](https://www.ruby-forum.com/u/al-evans)\ **Post date:** [April 20, 2006, 11:29pm UTC](https://www.ruby-forum.com/t/rails-fcgi-dreamhost/58348/6 "2006-04-20T23:29:10Z")
Dave S. wrote: > I just followed the quickstart guide from: > > [http://wiki.dreamhost.com/index.php/Ruby\_on\_Rails](http://wiki.dreamhost.com/index.php/Ruby_on_Rails) Interesting. I followed this when I first set the site up, but the “frao\_handler” bit led to an endless profusion of FCGI processes, and I had to take it out. I added a note to the wiki just below the initial recommendation. > ## …I do make quite extensive use of page caching so a lot of the time the Rails app isn’t actually doing anything > > maybe that’s where my scenario differs from yours? (Scott B. mentions this, too…) To be honest, I’m more interested for now in getting the best performance under the worst conditions:-) Sure, page caching is a great performance enhancer – but it doesn’t tell me anything about the underlying engine. > So have you just got wget / curl or something sending one of your Rails > pages > to /dev/null every 10 minutes? I wrote a Ruby script to do it, along with a controller action that just renders a bit of text. In the past 24 hours, I’ve had three of these responses: 500 Internal Server Error 500 Internal Server Error in [http://rtest.openprofile.net/ping](http://rtest.openprofile.net/ping) and one: Operation timed out - connect(2) Operation timed out - connect(2) in [http://rtest.openprofile.net/ping](http://rtest.openprofile.net/ping) I guess that’s about average in my experience so far. I wouldn’t want those results in a site somebody paid me to write:-) The 500 errors show up in the apache error log: FastCGI: incomplete headers (0 bytes) received from server “/home/anejr/rtest.openprofile.net/public/dispatch.fcgi” They show up in the fastcgi.crash.log as “asked to terminate immediately”. The timeouts don’t show up. > Have you added the stuff from step 5 of the quickstart guide, to prevent > your > FCGI from being killed off periodically? I’ve added it, and everything > seems > OK. As I said above, I tried that, and it didn’t work for me. But I’m intentionally not caching pages. > I didn’t know you could run Lighty on Dreamhost? Can anyone confirm, > because > if so I’d also quite like to do that. Note that I didn’t say you could! Just that I’ve seen this recommended as a solution, and it seems like it would work. Yes, they would have to configure it in Apache, and provide you with a port number. > Sorry to hear about your troubles though - I hope I’m not going to run > into > them as I put bigger and bigger Rails sites up on Dreamhost. I strongly recommend banging on your apps harder than your users will:-) –Al Evans