[TurboGears] Re: DreamHost deployment difficulties

[Sean De La Torre]

After some research, it looks like the common solution to keeping the fastCGI processes from dying is to set up a cron job to periodically hit the site using wget.

Here's a cron directive that I found that should work:

*/5 * * * * wget http://www.yoursite.com -O - -q >/dev/null 2>&1

A few references:

http://dev.scharfie.com/articles/2006/01/27/devbook-keep-alive
http://wrath.rubyonrails.org/pipermail/rails/2006-January/010879.html
http://wrath.rubyonrails.org/pipermail/rails/2006-January/010970.html
http://wiki.dreamhost.com/index.php/Cron

Sean

On 2/18/06, Sean De La Torre <[EMAIL PROTECTED]> wrote:

Vladimir,

I also see the slowness if I don't interact with my site frequently.  The problem is that the fastCGI processes die if they aren't in use.  However, on my site (I'm on the "rock" server), it takes about an hour before all of them die. 

If all the processes are down, then it takes about 30 seconds - 1 minute to get my site up and running.  Once it's up, it's pretty fast, so I don't see the same slowness that you see.

I'll let you now if I find a solution for the fastCGI processes.  As for the application slowness, are you using HTTPRedirect to redirect your application?

Sean

On 2/17/06, Vladimir Blagojevic < [EMAIL PROTECTED]> wrote:

Hi everybody,

I've been using TurboGears for a couple of months now. Great work guys.
I hope you can help me with my deployment problems.

I deployed my TurboGears app on DreamHost. Everything worked out as
advertised on the TG Wiki, and I was hilarious to see my app running.

And then the problems started.

If you don't interact with the webapp for a while, it takes a lot of
time to load. More than a minute. I saw that the server starts up
actually. And it's not only if you don't interact with it. It happened
also after just a few minutes playing around.

It's generally very slow to respond. I didn't profile to see where the
bottlenecks are, but even for simple operations - one query with few
records in the database - takes several seconds to execute.

The app has a lot of redirects: part of it is implemented using command
pattern, so eventually all commands get redirected to an appropriate
URL. After the command finishes, it redirects back to the main page.
Bad idea. Redirects don't really work always in this set up. Sometimes
you just don't get there. They make everything slower. I think that the
problem is that they go through the FastCGI instead of being resolved
by cherrypy. I still don't understand why is it that they don't work
every time.

And sessions - I had problems with them, but using following settings
seems to solve it:

sessionFilter.on = True

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---