On Aug 10, 8:44 pm, Dj Gilcrease <digitalx...@gmail.com> wrote:
> On Sun, Aug 9, 2009 at 4:17 PM, Graham
>
> Dumpleton<graham.dumple...@gmail.com> wrote:
> > On Aug 10, 6:07 am, Jumpfroggy <rocketmonk...@gmail.com> wrote:
> >> I'm hosting a bunch of django apps on a shared host with 80MB of
> >> application memory (Webfaction in this case). I've got a bunch of
> >> apps that are very infrequently used, but need to be online. I've
> >> already changed the httpd.conf:
>
> I just went though this process on Webfaction as well, so here is my
> apache conf, it might help
>
> LoadModule rewrite_module modules/mod_rewrite.so
> LoadModule wsgi_module modules/mod_wsgi.so
> LoadModule deflate_module modules/mod_deflate.so
> KeepAlive Off
> Timeout 300
> ServerLimit 1
> StartServers 1
> MaxClients 25
> MinSpareThreads 2
> MaxSpareThreads 4
These values for min and max threads are a bit dubious because you
have a single process and that will have fixed 25 threads. Usually
these are defined in multiples of ThreadsPerChild and not less like
this. Possibly just means the values are ignored.
> ThreadsPerChild 25
> MaxRequestsPerChild 5000
Don't see much point for MaxRequestsPerChild.
> WSGIPythonOptimize 1
Am dubious that turning on optimisation helps and can cause problems
if set to '2' as doc strings will be stripped.
> <VirtualHost *>
> ServerName demo.digitalxero.net
> DocumentRoot /home/digitalxero/webapps/wsgi/demo
> WSGIDaemonProcess demo.digitalxero.net threads=5
> maximum-requests=10000 inactivity-timeout=3600
> display-name=wsgi:demo_site
That is 1 hour for inactivity timeout. They possibly want something
less than that.
If you application does leak Python objects due to inability to break
reference count cycles, there shouldn't really be a need for maximum
requests.
> WSGIScriptAlias / /home/digitalxero/webapps/wsgi/demo/django.wsgi
> ErrorLog /home/digitalxero/webapps/wsgi/demo/error.log
> </VirtualHost>
>
> ...
>
> > Replace use of mod_python with mod_wsgi. Ensure you use prefork MPM
>
> Why prefork, in my testing I found that the worker MPM used less
> memory in the long run, it uses a little bit more during idle time,
> but scales better
Sorry, meant to say 'worker' rather than 'prefork'. DO NOT USE
PREFORK. Hmmm, that was a bad stuff up. :-)
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
