>> > > I will study this approach to try to learn more about the fastrouter > feature. My main problem with uWSGI at the moment is sort of feature > overload. I feel like uWSGI is doing so much of what nginx can do that > I try to avoid some things like the fastrouter. But this is perhaps my > lack of understanding that causes this.
Half-true (so it is not false :P) but remember that uWSGI have to works with other webservers or without webservers at all. Some feature that could be redundant in nginx is vital (for example) in Cherokee. By the way, take in account that nginx has no strong support for graceful management of dead upstreams, this is why i always put a fastrouter in the middle of a cluster. If a uWSGI instance dies, or it is overloaded, the fastrouter can move connections or enqueue them to alive servers (dead servers are completely removed, where nginx continue to connect) and all automatically. If i need to add nodes in the cluster i do not have to reconfigure nginx or the fastrouter. I simply "subscribe" my new instances. > > And if each vassal has 1 process and 10 threads and I have 10 vassals > it's possible that if one application has very high load it will not > have enough concurrency to handle the traffic. > > Does that sound right? > Yes, you referred to php in the start of the thread, and this should have lighted my brain. PHP is a very particular beast: On each request it create a new "php environment", load the file, execute it and destroy the environment. It works the same for cgi, fastcgi and mod_php (obviously in cgi mode it have to create the full process too). Python, (and 99% of the other languages) does not work in this way, each app is seen as an "application server" remaining in execution ready to serve request asap. Probably we could achieve a similar setup in python creating and destroying an interpreter at each request (obviously this is not as cheap as php) but how much memory we will lose at each cycle ? I will make some test, but i do not think it will be a kick-ass solution. The real solution (as requested by a mailing-list user some days ago, referring to zerg mode) would be having a single process for each app, and let the emperor dinamically launch zergs to instances requiring more power (statistically the vast majority of the apps works fine with only one process). We only need to find a safe way to measure when an app requires more workers... The workflow would be 1) emperor spawn instance 001 [ok] 2) instance 001 detects overload [to-be implemented] 3) instance 001 sends "help' message to the emperor [easy, emperor and vassals have a communication channel already opened] 4) the emperor launch a zerg that will attach to the new instance [easy] 5) instance 001 still detects overload (its internal counter is now 2) [to-be implemented] 6) instance 001 sends another help request 7) the emperor launch another zerg 8) instance 001 detects no more overload and sends zerokill message to the emperor (instance internal load counter is now 1) 9) the emperor reclaim the first launched zerg 10) instance 001 detects no more overload again (its load counter is now 0) 11) instance 001 sends zerokill to the emperor 12) the emperor reclaims the second (and last) zerg 13) return to point 2 :) If no one as objection in this design (obviously i will limit the number of zergs the emperor can spawn) i will start working on this after europython. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
