2008/10/22 Yish <[EMAIL PROTECTED]>: > > Thank Graham very helpful info, > > We are using Django, version 6410 with a couple patches applied and we > are currently using mod_wsgi in embedded mode. > > I tried using the WSGIImportScript before and if I remember right it > seemed to load up the python interpreter and a few modules but no the > brunt of django. It may be because my import script that I was > pointing to was just my django.wsgi file which just set up the path > and environs and then consisted of > > import django.core.handlers.wsgi > application = django.core.handlers.wsgi.WSGIHandler() > > Am I right in assuming I would also need to import the brunt of the > modules I was intending to use either directly or indirectly, or > should I have a separate import script for this?
Importing Django is a good start, as it itself takes a bit to load. If the way urls.py is being used results in deferred loading of modules only when URL is first used, then yes you would need to explicitly import any modules you want preload into the WSGI script file. Alternatively, if I am right, you could just do the imports in urls.py and then reference the callable objects from the modules instead of by string reference. http://docs.djangoproject.com/en/dev/topics/http/urls/#passing-callable-objects-instead-of-strings That way everything preloaded when urls.py gets imported by Django at startup. Note that I do not know if referencing callable objects directly in urls.py patterns results in any limitations or other issues. Graham > On Oct 20, 4:05 pm, "Graham Dumpleton" <[EMAIL PROTECTED]> > wrote: >> 2008/10/21 Yish <[EMAIL PROTECTED]>: >> >> >> >> > I've been looking through the mod_wsgi website and this group to see >> > if there are any strategies for dealing with apache processes that >> > have grown too large (memory leaks) and here is what I believe is the >> > current state of affairs. >> >> > A) Fix the memory leaks (Haven't found the cause yet for us but over >> > the course of 20K requests to a single machine about 5-10 of our 60 >> > httpd processes will have jumped from using just under 30 megs to over >> > 100 megs. Of course I am still trying to find the issue but in the >> > meantime need a solution to prevent my machine from swapping like >> > crazy) >> >> What Python web framework (if any) are you using and what version of >> that framework? >> >> > B) Set maximum requests to a small number. This will reduce the >> > duration taht a process is around for reducing the number of these >> > bloated processes that should exist simultaneously. >> >> Good start, just make sure you use right configuration method based on >> whether embedded mode or daemon mode used. >> >> > C) Write a shell/python script to kill the bad processes. This isn't a >> > bad option but I am wondering what is the best method to kill an httpd >> > process without affecting our users. E.g. if sent a kill -9 to the >> > process while it was handling the request, a user would experience an >> > error. Is there a way to prevent this from happening? >> >> For Apache child worker processes, what Apache does itself is send a >> SIGTERM every second until process exits, but if it doesn't exist >> after 3 seconds it sends a SIGKILL. >> >> For mod_wsgi daemon mode, a SIGTERM should cause daemon process to >> initiate a monitored orderly shutdown and the process itself will >> SIGKILL itself if shutdown timeout expires and it hasn't exited. The >> shutdown timeout defaults to 5 seconds. >> >> > D) Graham has talked about adding some functionality ala perls >> > SizeLimit to set a maximum RSS size limit for a process. There seems >> > to be some issues with this approach and it currently looks like the >> > project is on hold. >> >> Apparently doesn't work on Linux. >> >> > My questions is am I missing something and/or do others have a >> > preferred approach? >> >> > In regards to B or C, I currently prime all my httpd instances after >> > they have been spawned (using httpperf) to make sure that the python >> > interpreter, Django and all other modules have been loaded to prevent >> > latency for the first user to hit that process. Does anyone know if >> > there is a way to do that with mod_wsgi when a new process is created >> > using options B or C? >> >> You can use WSGIImportScript to designate script file to be loaded on >> process start, thus preloading your code. Point it at same WSGI script >> file as WSGIScriptAlias, however, you will need to manually use >> WSGIProcessGroup/WSGIApplication group in appropriate context to say >> where WSGIScriptAlias is executed as you need to say where it is for >> WSGIImportScript and it has to match. >> >> Search for WSGIImportScript in documentation and past mailing list messages. >> >> Graham > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
