Roberto, This sounds amazing, I have to say that I read your mail several times today trying to understand everything :-) There is a lot of thing there. It sounds like soon we will have a simple solution to deploy multiple sites on a server without having to modify a zillion files.
I like this graph very much : client -> webserver -> uwsgi emperor (router) -> uwsgi vassal -> client If I understand this correctly it means that we will not have to modify the webserver configuration each time we add a new vassal site. The only operation required would be to drop the appropriate uwsgi config in the vassal site and eventually add a line in the router configuration. In my original example the vassal site directory will probably be the "SERVER_NAME:SERVER_PORT": * example1.com * example1.com:8081 * example2.com Thank you for following this discussion. I am looking forward reading and testing your proposal. Regards, --yml On Tue, Feb 1, 2011 at 9:39 AM, Roberto De Ioris <[email protected]> wrote: > > > Thanks Roberto for this very fast response. I think that the <name> > > directive makes sense to me however it seems that wsgi spec call them > > differently : > > http://www.python.org/dev/peps/pep-0333/#url-reconstruction > > > > <http://www.python.org/dev/peps/pep-0333/#url-reconstruction>If I > > understand > > the document above in the wsgi vocabulary we are talking of : > > SERVER_NAME = <server_name> > > SERVER_PORT = <server_port> > > > > However at the end these are just names so if you prefer <name> and > <port> > > it is also fine with me :-) > > > > Regards, > > --yml > > > Ok, let's forget about this, i have re-thinked about it a lot. > > First of all: > > in 0.9.7-dev we have already ALL the items to allow mass hosting > > - routing > - auto spawn/reload > - monitoring > > The last two now works out of the box, thanks to emperor mode. > > The only relevant part is routing. > > Routing is needed because not all webserver support some form of > regexp-based upstream/source choosing, and even for those supporting it > (most notably nginx) this is too raw for complex scenario. > > The current routing implementation (if managed by a fast language as lua) > has a little overhead, but involves a lot of socket work. > > I have solved it last night implementing fd passing on unix socket. > > So, instead of having > > client -> router -> uwsgi -> router -> client > > we will have > > client -> router -> uwsgi -> client > > I did some benchmark and impact is pratically irrilevant (less than 0.5 %) > > The other thing left is how the router knows which socket respond to > specific server_name/host_name ? > > I have tested various options, but we have already a networked/fast > caching system, why not use it as the storage for server_name->socket_name > pair ? > > Every new instance can write data to the cache in the router/emperor so in > the instance we will have: > > import uwsgi > > uwsgi.cache_set('uwsgi.it', '/tmp/uwsgi.sock', 0, 'socket_of_emperor') > > def application(...): > ... > > > and in the router: > > import uwsgi > > def application(e, s): > return uwsgi.send_message( uwsgi.cache_get(e['HTTP_HOST']), 0, 0, > timeout, e['wsgi.input'].fileno(), -1) > > > (the last -1 arg will set unix fd passing) > > This is the standard case and obviously every instance can write more > domain names that maps to the same socket. > > With this new items you can write faster router+emperor stack, but as we > want to reach always the best performance i will release in the next hour > a > 'fastrouter' plugin that is simply the c-based (async-friendly) version of > the previous python-code: > > it parse the request, search host_name/server_name in the cache and > connect (and fd pass) to the uwsgi instance. > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
