Rails, FCGI, Dreamhost

Rails
1

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

2

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

3

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

Thanks,

–
Scott B.
Web D.
Electro Interactive

4

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. :wink:

~Dave

–

Dave S.
Rent-A-Monkey Website Development

PGP Key: http://www.rentamonkey.com/pgpkey.asc

5

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

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

PGP Key: http://www.rentamonkey.com/pgpkey.asc

6

Dave S. wrote:

I just followed the quickstart guide from:

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

and one:

Operation timed out - connect(2) Operation timed out - connect(2) in
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