2009/3/28 Duncan <[email protected]>: > > > > On Mar 25, 5:11 pm, Graham Dumpleton <[email protected]> > wrote: >> 2009/3/26 Duncan <[email protected]>: > >> > On Mar 24, 7:28 pm, Graham Dumpleton <[email protected]> >> > wrote: >> >> 2009/3/25 Duncan <[email protected]>: >> >> >> > Are there any issues that I might run into with 300+ virtual hosts, >> >> >> Are you currently using mod_python with 300+ virtual hosts with a >> >> Python web application hosted in each site? >> >> >> > or >> >> > anything I might need to be aware of beyond what's in the mod_userdir >> >> > thread I linked? >> >> >> There have been various other discussions which may be relevant and a >> >> better source of information. Depends a bit on what some of the goals >> >> are. >> >> > I'll trawl the group again to make sure I didn't miss anything. >> >> >> > It looks like this will be a good solution for my users and I just >> >> > want to make sure the transition is as smooth as possible. >> >> >> A few questions. >> >> >> How much memory are the Python applications running under each virtual >> >> host likely to take? This will be a factor if there are 300 of them. >> >> >> Are those applications likely to be used constantly and thus always >> >> need to be resident, or are they likely to be infrequently used and >> >> thus don't strictly need to always be running? This plays into the >> >> memory question as far as solutions to trying to reduce memory usage. >> >> >> Do the applications running under each virtual host need to run with >> >> the permissions of a specific user who is the owner of that account? >> >> >> Answer that to clarify things and will see if can find better past >> >> threads where this has been discussed. >> >> > Graham, >> >> > Sorry for not including much data when I first posted; I wasn't sure >> > what was relevant. We provide shared hosting, so our users work with >> > the applications that meet their needs, be they PHP, Rails, or Python. >> > This is not a homogenous environment, so even with mod_wsgi we >> > wouldn't have every user running the same applications. If it's >> > relevant, we're also looking at adding support for frameworks like >> > Django, pylons, and turbogears. >> >> > I think at the moment no more than fifty of our sites are using Python >> > apps; we have Trac installs, fckeditor, bblog, firestats, bugzilla, >> > and some applications developed by users. Applications should run with >> > the permissions of the account they're run under; we use suexec for >> > PHP applications already. RAM usage is not a primary concern at this >> > time, since we're not primarily a Python host. >> >> Okay, one more question. Is whether they want to use Python as web >> application language something they have to opt in for in some way, or >> is that decision purely up to them and they would start using Python >> without you even knowing? > > It's purely up to them; the only time we'd hear about what language > they're using is if there's a security issue or they ask for > assistance installing the software.
And that is the core problem and why I have said previously that mod_wsgi may not yet be adequate enough for general commodity web hosting. The issue is that daemon process groups in mod_wsgi are statically defined by the configuration. Thus, in your situation you would need to preconfigure a daemon process group, say the default single process, for every VirtualHost you set up for a customer, just in case they might want to use Python. Although lazy loading for WSGI applications is the default and so no significant memory is taken up until that occurs, it does still mean that you have an idle process sitting there doing nothing for anyone not actually using Python. It may not cause much overhead if a small number of sites, but if you have 300 sites and thus 300 such processes then it would be significant. The best you could achieve prior to transient/dynamic daemon processes being implemented as per: http://code.google.com/p/modwsgi/issues/detail?id=22 and outlined in the mod_wsgi roadmap described at: http://blog.dscpl.com.au/2009/03/future-roadmap-for-modwsgi.html is to do the following. The first thing is to ensure that embedded mode of mod_wsgi is disabled. For your case this would be better done at compile time by supplying the '--disable-embedded' option to the 'configure' script when building mod_wsgi. if this is not possible, then set the directive: WSGIRestrictEmbedded On This step is to ensure that no customers WSGI application accidentally runs in the context of the Apache child server processes. You can then setup: AddHandler wsgi-script .wsgi as explained in the documentation: http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines and that other post you referenced. When they actually try and use mod_wsgi to host their WSGI application by using a .wsgi script file though, they will actually get a 500 error though. In the Apache error logs, that for the VirtualHost if correct configured to have its own, you would get an error of the form: Embedded mode of mod_wsgi disabled at compile time: /some/path/django.wsgi or: Embedded mode of mod_wsgi disabled by runtime configuration: /some/path/django.wsgi depending on how you disable embedded mode. The idea would be that you would have to document that if a customers wants to use mod_wsgi to host a Python web application, they would have to request it. If they tried anyway, they would get that error. You would then have to add into the VirtualHost for that customer: WSGIDaemonProcess site.com user=xxx group=yyy WSGIProcessGroup site.com WSGIRestrictProcess site.com An Apache restart would then be required, which would see the daemon process for that customer created. There application would then run. That a restart is required is the problem. For a large number of sites doing a restart is not desirable because it can affect availability of all sites. This can be lessoned using a graceful restart, but that in itself can have issues as far as overall memory resources during the cutover. So, right now, whether the static configuration requirements of mod_wsgi is going to be a problem will depend on how many sites you have. You either always preconfigure a daemon process with a waste of resources for something if not actually used. Or you delay the actual setup of the daemon process and suffer the consequences of doing a restart to enable it. For very very large Apache installations web hosting companies may not even use VirtualHost but use other virtual host mechanisms, perhaps with configuration driven off a LDAP server. Not sure if you are using VirtualHost or some other virtual hosting mechanism, but other mechanisms driven from a lDAP configuration are more of a problem. In these set ups they don't even need to restart Apache to add a new site, so having to do so for adding a mod_wsgi daemon process group would be even more onerous. This is why the transient/dynamic daemon process group feature if going to be pursued. Such that a hosting service like yourself can define a template for how a daemon process group is setup, but with daemon processes only actually being created when required, with them being shutdown when idle. This way if only a few customers use Python and mod_wsgi, then only sufficient processes for them are created, with them being automatically shutdown if their application is infrequently used. Right now you therefore need to think about how much manual configuration and restarts you can tolerate. If the current requirements are not acceptable then you will want to wait until transient/dynamic daemon process group feature is available. Anyway, give me an indication of what is an isn't acceptable as far as how you manage your configuration and how you bring new sites online and we can go further and look more at specific setup instructions if documentation and old discussion threads are not sufficient. 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 -~----------~----~----~----~------~----~------~--~---
