On Thu, Oct 30, 2008 at 10:58 PM, Graham Dumpleton < [EMAIL PROTECTED]> wrote:
> > 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. Indeed both these options sound useful. I already use MaxRequestsPerChild for Apache, but having the same for the Python daemon process makes sense. The inactivity-timeout will be useful since I have cronjobs that run during low traffic hours to do random work and will benefit from more available memory. (My WSGIDaemonProcess line is becoming a little too long, can it be split to multiple lines?) > 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. Yep, Keep-Alive off makes a decent difference when I'm benchmarking a single dynamic script with some concurrency (and the benchmarking client is explicitly not reusing connections). And since I dont have many (any?) cases of immediate follow up requests, Keep-Alive is not very useful for now. I am quite amazed at how well mod_wsgi performs for my simple wsgi applications :) > 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. That's interesting. I wonder if Apache could be made to reject such requests. I like the current simple setup - I want to avoid adding Nginx to the mix :) > > 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. I wasnt sure if this was needed or not - but as long as it doesnt do harm, I'm inclined to keep it. > > <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. PHP is indeed why you're seeing this here - but finally once I'm done with my current migration, the last PHP site will be gone. I was planning on switching to worker, but just yesterday realized that my distro only comes with the prefork mpm. So if I'm going to be building a custom Apache package anyways, maybe I should go with event. mod_wsgi is already a custom package, so rebuilding that is a non issue. > > 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. > Took it out. Less is always better :) Thanks! -Naitik --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
