I can't recommend either of those solutions specifically, but I have been
using an approach similar to that of django-multisite running on a threaded
fastcgi instance since django .96 days and it has worked well for us. My
main concern would be with third-party apps that set static data initially
from settings, and would bypass any per-request changes. A seconday
concern is with caching and handling cached templates, which means writing
your own per-site template loader or not using template caching.
You can host multiple domains from one instance with a bit of work and
auditing all the 3rd pary code you use to make sure it does what you
expect, but it does add some quirks. Worth it for the memory savings in my
opinion though if you are willing to be careful and you are doing very
little other than template customization for each site. It also makes
maintenance and upgrades much simpler.
On Tuesday, September 17, 2013 4:12:32 AM UTC-5, James Zildjian wrote:
>
>
> Hi
>
> I am trying to run around 50 mini sites which share about 90% of their
> code. Each site simply queries and API and returns the results, and will be
> on it's own domain, and have a different style.css and config.py. The
> userbase (and the database generally) will be shared across the board. My
> initial idea was to run them as separate applications with a common
> library, each with their own UWSGI thread. However, I have concerns about
> large memory use.
>
> I have read about the sites framework which would allow them to run from a
> single instance.
> 4
>
> https://docs.djangoproject.com/en/dev/ref/contrib/sites/
>
> My question is, is the site framework the right approach to a problem like
> this, and does it have real benefits over running separate applications. I
> have heard the following:
>
> *Your SITE_ID is set in settings.py, so in order to have multiple sites,
> you need multiple settings.py configurations, which means multiple distinct
> processes/instances. You can of course share the code base between them,
> but each site will need a dedicated worker / WSGIDaemon to serve the site.
> *
>
> Alternative ideas of systems:
>
> https://github.com/iivvoo/django_layers
> https://github.com/shestera/django-multisite
>
> Any ideas or help would be most appreciated.
>
> James
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
