Sorry, this gets a little long winded. On Sun, Jun 19, 2011 at 1:41 AM, Roberto De Ioris <[email protected]> wrote: > >>> >> >> 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.
This still requires me to maintain two lists of information though, basically a set of parallel configurations. I need the hostnames in the webserver since it is what's receiving the traffic, then I must also make sure the fastrouter is working the same way via domains.txt and subscriptions and a possibly not yet implemented regex. I am desperate to consolidate and simplify my configuration. This is why virtual mode is so appealing, I can get by without changing anything except the webserver config which is impossible to avoid anyway. > > > >> >> 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. I know that popular Python servers work 100% differently than PHP because they are resident applications, I was only referring to the ease of use of PHP-FPM. uWSGI's virtual mode mimics this to a degree, meaning that uWSGI doesn't need any foreknowledge of the application before it is run and allows me to set a global resource size. > > 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. Yes, I would never suggest that strategy. Python isn't built for speedy startup like PHP so you would incur a ton of overhead from starting and stopping the interpreter each time, talk about slow TTFB. :) > > 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. I love Zerg! This could automatically handle the change in load over time but the config still seems complex, even if I don't completely understand the fastrouter concept. Ultimately your resource consumption still rises linearly as your number of applications increase due to the emperor mode, right? Since each application means at minimum one additional process. How does virtual mode share multiple applications in the same set of processes? Are multiple applications running from within the same interpreter instance? If so I can see why collecting individual applications would be complex or impossible. Combining some of these concepts could be very powerful. I hate mentioning PHP-FPM again, but the one thing that annoying PHP people keep holding over my head is the absolute simplicity and ease of deploying PHP applications. A concrete example of the absolute best use case I could think of would be if the uWSGI master process or an emperor type process handled all of the communication from the web server to the workers. This would make configuring any web server trivial as you just pass the socket and entry point to uWSGI. If that entry point isn't already running uWSGI would initialize it. Transparently this process could create and terminate application workers on demand as well as keep an eye on load and increase the number of processes or reduce them (all the way down to zero if needed). I think what I'm describing is half emperor mode and half virtual mode. What this would enable is an automatic layer that could find, run and even scale python applications on demand. Applications that did not receive traffic, would not use memory or CPU. Every sysadmin I know running any sort of shared environment would toss apache and mod_wsgi out of the window at that point. To conclude this over long message, the reason uWSGI is so attractive to me is because I can run it in a way where it requires no foreknowledge of the applications it will be running. Having a completely decoupled layer that manages python applications is valuable, and amazing. You can't get out of adding configs to the web server, but if that's the only place I have to do it I'll consider it a good day. Trey Long. PS: If you ever need help trying to write or make documentation clearer I would be happy to help. > > > > -- > 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
