RE: Production deployment on Dreamhost?


#1

Yup just figured that out…

Do you think that this would solve the issue where my app sometimes
takes 30-40 seconds to “start up” after it’s not been used for awhile?
I’d hate for a client website to have to wait that long to serve up a
search page or something.


#2

I face the same think when using rails on dreamhost with fcgi. The app
needs to startup sometimes (and this takes a lot of cpu time)…


#3

Abdur-Rahman A. wrote:

I face the same think when using rails on dreamhost with fcgi. The app
needs to startup sometimes (and this takes a lot of cpu time)…

I’m not sure about deployment on Dreamhost, but if I remember correctly
I think there are maintenance things that you can do on your app to keep
it running up to speed.

I’m still noobish with Rails, but I think I read something about
clearing your logs and files like that to keep Rails apps running
faster.

Might be an aside to the question, but I remembered it and thought it
might be of note for other new Railers. Anyone have any more
details/specifics on what I am talking about?


#4

On Jan 12, 2006, at 3:05 PM, Hogan, Brian P. wrote:

Yup just figured that out…

Do you think that this would solve the issue where my app sometimes
takes 30-40 seconds to “start up” after it’s not been used for awhile?
I’d hate for a client website to have to wait that long to serve up a
search page or something.

This has come up several times on the list recently. The problem seems
to be that the fcgi processes get paged out of memory after a while,
causing a delay when they get swapped back in. A workaround would be to
set up a cron job that uses wget to hit your site every few minutes.
This’ll keep the process in memory so it’ll be more responsive. I
haven’t
had this problem myself, so I’m just parroting what I’ve heard
elsewhere.
YMMV.

-dudley


#5

Dudley F. wrote:

This has come up several times on the list recently. The problem seems
to be that the fcgi processes get paged out of memory after a while,
causing a delay when they get swapped back in. A workaround would be to
set up a cron job that uses wget to hit your site every few minutes.
This’ll keep the process in memory so it’ll be more responsive. I haven’t
had this problem myself, so I’m just parroting what I’ve heard elsewhere.
YMMV.

There was a thread “Idle Apache+FastCGI sleeping?” in which Ezra
Zygmuntowicz gave this advice:

I have seen this behavior before. It seems to me that when the
fcgi’s sit idle for too long they get paged out of memory. Then when
you hit the site after its been idle, the fcgi’s have to page back
into memory so hence the lag. The kludge that I use works great but
I’d be interested if there was another way. But this technique works
great in production for me.

Just add a cron job that uses curl or wget to grab a page thats not
cached(so it goes through rails) and send the output to /dev/null. If
you have the cron job do this once every 5 minutes your fcgi’s will
always be ‘awake’ . And one hit every 5 minutes is virtually no extra
load on the server. But by doing things this way, your site will
always be snappy no matter how long it has been since a user visited
the site.


#6

I think Ezra should have a cron job to send out that email every 10
days…
it seems to be a common problem.


#7

On Jan 12, 2006, at 8:49 PM, Tom F. wrote:

I think Ezra should have a cron job to send out that email every 10
days…
it seems to be a common problem.

Great Idea! lol

-Ezra

elsewhere.
great in production for me.
Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

-Ezra Z.
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
removed_email_address@domain.invalid


#8

Good info here guys. I just deployed on Dreamhost as well, and
everything
ain’t so “dreamy”. Hopefully these fixes will speed things up.

Are you guys freezing edge or anything on there? I noticed on my box at
least they were running an older version of rails. 0.14.3 I believe.