# 24 seconds for FASTCGI process to startup? Is this normal? **URL:** \ **Category:** Ruby\ **Created:** [August 12, 2007, 10:56pm UTC](https://www.ruby-forum.com/t/24-seconds-for-fastcgi-process-to-startup-is-this-normal/111880 "2007-08-12T22:56:33Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [August 12, 2007, 10:56pm UTC](https://www.ruby-forum.com/t/24-seconds-for-fastcgi-process-to-startup-is-this-normal/111880/1 "2007-08-12T22:56:33Z")
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 workaround[http://work.alexyoung.org/archives/102/dreamhost-and-rails-500-errors](http://work.alexyoung.org/archives/102/dreamhost-and-rails-500-errors), adapted from Gary L.'s workaround[http://thread.gmane.org/gmane.comp.lang.ruby.rails/33057](http://thread.gmane.org/gmane.comp.lang.ruby.rails/33057)seems 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 ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [August 13, 2007, 10:13am UTC](https://www.ruby-forum.com/t/24-seconds-for-fastcgi-process-to-startup-is-this-normal/111880/2 "2007-08-13T10:13:18Z")
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) ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [August 13, 2007, 4:44pm UTC](https://www.ruby-forum.com/t/24-seconds-for-fastcgi-process-to-startup-is-this-normal/111880/3 "2007-08-13T16:44:50Z")
> 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/](http://my.domain.com/) > dev/null Hope that helps, Chris ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [August 15, 2007, 8:30am UTC](https://www.ruby-forum.com/t/24-seconds-for-fastcgi-process-to-startup-is-this-normal/111880/4 "2007-08-15T08:30:41Z")
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 ---
**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\ **Post date:** [August 15, 2007, 6:59pm UTC](https://www.ruby-forum.com/t/24-seconds-for-fastcgi-process-to-startup-is-this-normal/111880/5 "2007-08-15T18:59:41Z")
> 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