24 seconds for FASTCGI process to startup? Is this normal?

Ruby
1

Hi,

I’m on Dreamhost for hosting and have been finding that (noting
Dreamhost
kill off ruby processes) the first page return takes 20-40seconds, after
which things go ok. I’ve put some logging in the “dispatch.fcgi” code
and
note the following:

  • HTTP log output for initial request: X seconds
  • “dispatch.fcgi” entry: 1 second after this
  • fastcgi process log entry: 24 seconds after last step
  • my RoR app log entry: 1 second after last step

Question - Is it normal for the fastcgi processes to take this long to
start
up? Any suggestions on how to improve startup time?

Note: I am aware of a work around mentioned on the Dreamhost wiki which
I
will try (see below), however I wanted to make sure I can’t optimize the
root cause start up time before going into work around mode.

If you are using fcgi with Ruby on Rails, you might get what appear to
be
random 500 errors occasionally. Alex Y.'s
workaroundhttp://work.alexyoung.org/archives/102/dreamhost-and-rails-500-errors,
adapted from Gary L.'s
workaroundhttp://thread.gmane.org/gmane.comp.lang.ruby.rails/33057seems
to resolve this. Basically, add the following code to your
dispatch.fcgi, right before RailsFCGIHandler.process! class

RailsFCGIHandler
private
def frao_handler(signal)
dispatcher_log :info, “asked to terminate immediately”
dispatcher_log :info, “frao handler working its magic!”
restart_handler(signal)
end
alias_method :exit_now_handler, :frao_handler

Regards

2

On Aug 12, 2007, at 3:55 PM, Greg H. wrote:

  • HTTP log output for initial request: X seconds
    will try (see below), however I wanted to make sure I can’t
    33057>seems
    alias_method :exit_now_handler, :frao_handler

Regards

Uh, yeah, often that can happen. It’s shared hosting.
If you want something faster and more dedicated to your app, you’ll
need to move to some sort of VPS hosting (virtual private server)
where you pay for a slice of memory and processor time in your hosting.
FCGI is better than CGI.
DH does not allow persistent processes on their shared hosting. Even
while installing your own gems in your directory, their system will
occasionally kill it if it takes too long.

Still this may be more of a Rails question, as it pertains mainly to
rails and not so much to Ruby CGI specifically.
That said, it’s also actually more appropriate for the DreamHost
forums or to contact DH support (they are very responsive if you ask
nice questions)

3

Any suggestions on how to improve startup time?

As mentioned, you’ll probably get better help on the rails or dreamhost
forums.

Having said that, I had a similar problem on dreamhost and solved it
using a cron job that periodically accessed my rails app,

0,5,10,15,20,25,30,35,40,45,50,55 * * * * curl -s http://my.domain.com/

dev/null

Hope that helps,

Chris

4

Thanks Chris - I’ll try this.

Any ideas on whether this approach would assist in keeping more than 1
fastcgi? I note that there are 2-3 processes fastcgi ruby processes
that
Dreamhost seems to kickoff when I hit the website (I’m not sure where
this
number is specified).

Cheers
Greg

5

Any ideas on whether this approach would assist in keeping more than 1
fastcgi? I note that there are 2-3 processes fastcgi ruby processes
that
Dreamhost seems to kickoff when I hit the website (I’m not sure where
this
number is specified).

I’m not sure where I got this tip from, but try adding this to your
crontab :

10 1 * * * ps aux|grep username|grep dispatch|awk ‘{print $2}’|xargs
kill -9

(replace username with your dreamhost username). It periodically kills
dispatch processes, which are then recreated by the app. It seems to
keep the number of dispatch processes for my app to around 3. Without
it, I found a lot of stale processes were created. If I recall, this can
be caused by errors in your app (check production.log), so perhaps I
don’t need this anymore. But it doesn’t seem to hurt!

Hope this helps,

Chris