2009/3/23 [email protected] <[email protected]>: > > Hi Graham, > Thanks for your uber-fast response. I see exactly what you mean with > the pre-set processes and rewrite map - and it's a great work around > till the v4.0 release. Many thanks. > > But are you saying daemon mode is only preferable due to the tendency > for apache to be misconfigured?
I am presuming you are talking about issues described in: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html > A correctly configured apache set up > would be able to handle the embedded dynamic set up (and be better > performing too)? The performance difference for a large Python web application is probably not going to be that significantly different for the two modes as the performance of Apache/mod_wsgi isn't going to be the bottleneck. The determining factor may there be amount of memory used in your case. For embedded mode, where using separate application group for each site, you have a copy of every site in every process. For daemon mode, provided application is multithread safe, can probably get away with one multithreaded daemon process. Thus your memory requirements are much much less as only one copy of each site instead of a copy in every child process. My advice these days would be to use daemon mode unless you have a very good reason not to and can show through testing of your specific application that using embedded mode is warranted. If using embedded mode, at same time, you would need to go to effort of configuring Apache MPM settings appropriately, as well as perhaps setting up a separate media server. With daemon mode, you can at least leave Apache MPM settings set up for static media and use same server. This isn't necessarily a good if using embedded mode as static file serving and dynamic web application have different requirements as to what MPM settings should be. Graham > Ben > > > > > On Mar 23, 10:49 am, Graham Dumpleton <[email protected]> > wrote: >> 2009/3/23 [email protected] <[email protected]>: >> >> >> >> >> >> > Hi Graham, >> > One final question. The scripts above required a wsgi file per site. >> > I've rewritten it to direct all the sites through a single .wsgi file, >> > then used thin wrapper round the application to send it on its way to >> > the correct (django) settings based on environs settings. This seems >> > to work pretty well, even though it removes the 'touch' reloading >> > method. >> >> > But I'm concerned whether this script might be setting itself up for a >> > fall due to the way modwsgi is handling apache processes in embedded >> > mode since a new application group is being defined for each site >> > (which it needs to be since each site may be operating in different >> > virtualenv)? Isn't this what the daemon process mode is for? I'm >> > thinking of this line from the Configuration Guidelines: >> >> > 'Where multiple applications, potentially owned by different users, >> > need to be run, 'daemon' mode of mod_wsgi should instead be used." >> >> Using daemon mode would certainly be preferable, but as you already >> know, one can do it with different application groups (sub >> interpreters) within same process. >> >> > If that's true can the daemon process name be defined dynamically? Or >> > does this method necessarily require embedded mode? >> >> You can switch it around. >> >> WSGIProcessGroup %{ENV:subdomain} >> WSGIApplicationGroup %{GLOBAL} >> >> The only problem with this is that you then need to statically define >> a WSGIDaemonProcess directive for each sub domain, which is contrary >> to what your original aims were from memory. That is, to not have to >> change the Apache configuration to add a new site. >> >> One of the main aims in mod_wsgi 4.0, see: >> >> http://blog.dscpl.com.au/2009/03/future-roadmap-for-modwsgi.html >> >> is to provide support for dynamic creation of daemon process groups >> through defining only a single parameterisable template. >> >> So, you will not get exactly what you wish until then. >> >> The closest thing you will get for now is to define in advance >> WSGIDaemonProcess directives for a pool of daemon process groups. This >> would be given generic names. You would then use a RewriteMap to >> dynamically assign stuff for a sub domain to one of the daemon process >> groups in the pool of daemon process groups. >> >> WSGIDaemonProcess site-1 >> WSGIDaemonProcess site-2 >> WSGIDaemonProcess site-3 >> WSGIDaemonProcess site-4 >> WSGIDaemonProcess site-5 >> WSGIDaemonProcess site-6 >> WSGIDaemonProcess site-7 >> >> RewriteEngine On >> RewriteMap wsgiprocmap txt:/etc/httpd/wsgiprocmap.txt >> RewriteRule . - [E=PROCESS_GROUP:${wsgiprocmap:%{ENV:subdomain}}] >> >> WSGIProcessGroup %{ENV:PROCESS_GROUP} >> >> Then when you add a new site, as well as creating directories in file >> system, add an entry in the rewrite map, such as: >> >> foobar.com site-1 >> >> Does mean you have to do some manual stuff in Apache configuration, >> but you can at least preconfigure a whole bunch and then map then with >> the write map file without having to restart Apache, as Apache will >> automatically reread the rewrite map file when it changes. >> >> Have I captured the intent of what you are trying to do? >> >> Graham >> >> > Once again, many thanks for your advice on this. >> > Ben >> >> > On Mar 15, 12:20 am, Graham Dumpleton <[email protected]> >> > wrote: >> >> Bouncing this back onto list for general interest. >> >> >> 2009/3/15 [email protected] <[email protected]>: >> >> >> > Been meaning to do this for ages now. Thanks Graham for all your help >> >> > in other posts about this. Anyhow, following on from the thread as >> >> > mentioned above, script below includes media handling, using >> >> > VirtualDocumentRoot as mentioned above. The hard work was really >> >> > already done above and this one has been modified to handle >> >> > subdomains, using the subdomain name to identify the relevant >> >> > folders. >> >> >> > I only just got it work and have posted it in a slightly overexcited >> >> > way so probably needs tidying and strengthening. But any obvservations >> >> > most welcome (yup favicon not handled), thanks: >> >> >> > RewriteEngine on >> >> > RewriteMap tolower int:tolower >> >> >> > VirtualDocumentRoot /home/sites/static/%1/ >> >> >> > <Directory /home/sites/static/* > >> >> > Order deny,allow >> >> > Allow from all >> >> > </Directory> >> >> >> > RewriteCond %{HTTP_HOST} ^([^.]+)\.domain\.co\.uk$ [NC] >> >> > RewriteRule . - [E=subdomain:%1] >> >> >> > RewriteCond %{REQUEST_URI} !^/media/* >> >> > RewriteCond %{REQUEST_URL} !^favicon.ico >> >> > RewriteRule ^/(.*) /home/sites/init/modwsgi/${tolower:% >> >> > {ENV:subdomain}}/django.wsgi/$1 >> >> > RewriteRule . - [E=APPLICATION_GROUP:${tolower:%{SERVER_NAME}}] >> >> >> > WSGIProcessGroup %{GLOBAL} >> >> > WSGIApplicationGroup %{ENV:subdomain} >> >> >> > <Directory /home/sites/init/modwsgi/* > >> >> > Order allow,deny >> >> > Allow from all >> >> > Options ExecCGI >> >> > AddHandler wsgi-script .wsgi >> >> > </Directory> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
