[1] http://blog.dreamhosters.com/kbase/index.cgi?area=3118
On 2/18/06, Eric Brown <[EMAIL PROTECTED]> wrote:
I think the rails guys have run into similar problems. They've come up with a couple of solutions.Summarizing:* Apache 1.3 with fastcgi is recommended over apache 2* If using apache 2, use fcgid* For real web sites (non-development), don't use dynamic fastcgi processes, use static (doesn't die so no need for cron job)* lighty maybe is or maybe is not stable enough to use* One interesting scenario if apache2 is a must is to use mod_proxy to a lighty serverThe configuration for configuring fastcgi (presumably apache 1.3, not apache2/fcgid) is here:Another very interesting analysis: (apache2 -> lighty recommendation)On Feb 18, 2006, at 8:04 AM, Sean De La Torre wrote: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:A few references:*/5 * * * * wget http://www.yoursite.com -O - -q >/dev/null 2>&1
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
SeanOn 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?
SeanOn 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
