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