Gunicorn: Some way to serve many WSGI apps via the same gunicorn instance.

Created on 29 Mar 2010  ·  7Comments  ·  Source: benoitc/gunicorn

Do you think it's a good idea if we have some way to run lots of applications via the same gunicorn instance, so that they use the same python interpreter(s).
At least for me, this will be very useful, because it'll save lots of RAM, as I have many small applications (with very low load) that run on the same machine.

Add Example

Most helpful comment

I have to agree wtih jbergstroem that this doesn't belong in core. But I did go ahead and add an example outlining how you can accomplish this with Routes:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

All 7 comments

I think this kind of behavior is best solved by the end user. There's a distinct difference in the way gunicorn works with "multiple sites" compared to a conventional web server.
I would suggest using some simple python library such as werkzeug and make your two apps respond on different routes.

I have to agree wtih jbergstroem that this doesn't belong in core. But I did go ahead and add an example outlining how you can accomplish this with Routes:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

instead of havint a specific mount point per apps, would it be possible to have an example with virtual host by name?

Yes, it is totally possible. You can write a trivial mapping of environ['HTTP_HOST'] to apps.

I think this could be built in gunicorn, what do you think?

This could be some optional part of gunicorn, like contrib stuff, yes.

I think it would be best as a standalone multiplexor application with separate config. Django/Paste specialization must also go there. Like this:

$ gunicorn wsgi_multi django:project1 myblog.wsgi:wsgi_app anotherapp.foo

Here, gunicorn runs only one application wsgi_multi, other arguments are passed to it via some special API. Or via config or somehow else.

I spent a lot of time trying to write something like what is suggested in this ticket. First I tried having code that switched virtualenv based on HTTP_HOST. Turns out you really can't deactivate virtualenvs in pure python, so that was a wash.

Then I thought: maybe we can just have a requirement that it's one single virtualenv, so I wrote the code to switch to different WSGI apps based on HTTP_HOST only to discover that you can't run two django apps side by side because django keeps a truly astonishing number of global variables everywhere.

So basically, what I'm saying is it's not all as easy or even feasible as suggested above.

Maybe it's more feasible to do some kind of load balancing thing where workers run in different virtualenvs depending on the app and a central gunicorn master makes sure that the apps that needs more workers get them? Probably not easy or fun to write :(

I'd really like for django to be cleaned up to make this kind of thing possible...

Was this page helpful?
0 / 5 - 0 ratings