This sound a bit similar than puting The fastrouter directly behind varnish. So if I understand well It will avoid the overhead of The fastrouter. Regards
Le 15 sept. 2011 18:20, "Roberto De Ioris" <[email protected]> a écrit : > Dnia Å›roda, 14 wrzeÅ›nia 2011 o 20:19:45 Roberto De Ioris napisaÅ‚(a): >> > BTW is subscription server single process? Can I have multiple SS >> > processes >> > listening... Well, the best approach seems to have a subscription server that send its data (domain names and backends) to varnish via its admin protocol. Varnish will continue to directly connect to uWSGI instances (in native http mode) but its configuration will be constantly upgraded/adapted by this additional (and very cheap) process. At low level it will became something like this: uWSGI node1 subscribe to subscription server uWSGI node2 subscribe to subscription server subscription server constabtly check if something is changed and eventually generate a new director stanza for varnish and will update it via its internal admin protocol. Someone interested in this kind of plugin ? Maybe we could follow a more generic approach and execute custom code in a dumb subscription server: def status_change(domain_name): # something is changed for domain domain_name # get the node list from the 'dumb' subscription server nodes = uwsgi.get_subscription_nodes('dumb',domain_name) # generate and send to varnish (or you could do whatever you want) send_to_varnish(""" director foobar { backend node1 { .... .... } } """) -- 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
