Thanks a lot for your patience going through the ABC with this. I can't give enough thanks for your constant and inspirational open- source work and the help you give to stragglers like myself. I hope in the not too distant future i can at least come back with enough beer tokens to last a while, not just the words. Cheers and have a good day, Ben
On Mar 23, 11:23 am, Graham Dumpleton <[email protected]> wrote: > 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-usa... > > > 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 -~----------~----~----~----~------~----~------~--~---
