On Oct 31, 4:09 pm, "Naitik Shah" <[EMAIL PROTECTED]> wrote:
> > Also indicate how much traffic each site gets and whether any would
> > potentially be idle for periods, as can then look at inactivity
> > timeouts etc.
>
> As embarrassing as it sounds, I don't have good numbers available yet. There
> are definite idle periods on certain virtual hosts.
If there are definite idle periods of reasonable size, perhaps look at
'inactivity-timeout' option to WSGIDaemonProcess. This way daemon
process will be restarted when doing nothing, and providing that
preloading not configured using WSGIImportScript, then process size
will be quite small until next needed, at which point it will load
application again.
To counter risk of daemon process growing in size because of memory
creep in application you don't know about, also look at 'maximum-
requests' option to WSGIDaemonProcess.
> > Rather than event MPM, would suggest using nginx as a front end, with
> > nginx serving requests for static files and then proxying other
> > requests through to Apache/mod_wsgi. This is because nginx is arguably
> > better at serving static files and maintaining many open connections
> > with keep alive. The Apache/mod_wsgi instance would then only be
> > handling dynamic requests and all connections would come from local
> > nginx. Even if keep alive working there, depending on how optimised
> > nginx is, it can possibly reuse the connections over time for requests
> > from different originating clients in a more efficient way, thereby
> > keeping the memory overhead in Apache which generally arises from
> > maintaining open connections from lots of different clients.
>
> I considered nginx, but I've been playing with S3 and I think I'm going to
> use that as a poor mans edge system for my static content. But I'll keep
> this in mind. Would using a event mpm help if I didnt have to serve static
> content or need Keep-Alive?
If Apache/mod_wsgi only handling dynamic content, wouldn't see that
event MPM would make any difference. If only handling dynamic content,
turning off keep alive on Apache may help though as unlikely one will
get concurrent requests over same socket for dynamic web page, and so
can give up client connection straight away and not tie up Apache
processes/threads for period that timeout takes to trigger for keep
alive.
In respect of having nginx in front, one of the over benefits of that
was that nginx could have been quite selective about the URLs that it
was proxying. That way if you get a SPAM bot or similar hitting the
site, it could have been blocked at nginx without even going through
to Apache/mod_wsgi, presuming that such a bot was hitting known URLs
for security holes in PHP packages or the like. One may also have been
able to filter SPAM bot traffic at nginx level through user agent or
other things. Thus, nginx could have further been used as a filter
point to limit traffic going through to Apache.
> WSGIPythonOptimize 1
Surprised if this will make much difference. Worth a try but don't
expect it to do much. For a start, as it is a long running process,
any benefit at process start when loading smaller .pyo files is only
for that time and not later when handling actual requests.
> <IfModule mpm_prefork_module>
> StartServers 30
> MinSpareServers 30
> MaxClients 30
> </IfModule>
If not using PHP on same Apache, better to use Apache worker MPM as
then cut down on number of Apache child process and still just as
capable at handling load of static files and proxying to mod_wsgi
daemon processes.
> Alias /media/ /data/daaku/media/
> <Directory /data/daaku/media/>
> SetHandler None
The 'SetHandler None' should not be needed here. This was a mod_python
requirement but mod_wsgi shouldn't need it.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
