Il giorno 28/giu/2011, alle ore 07.47, Yaniv Aknin ha scritto: > Hi Roberto, all, > > Recently there have been quite a few features that revolve around adding more > processes to handle more load. I'd appreciate it if someone here could > explain how this helps precisely. > > I can understand why adding processes up to the number of cores is helpful > (because you will utilize all cores in the machine). > I can understand why adding processes to a slightly higher number of cores is > helpful (because you will decrease the chance of losing CPU time when workers > are blocking on something). > > But I'm not sure I understand why it makes sense to run 20 or 40 or 80 > workers on a machine with only 4 cores, even if it has enough RAM for all of > them; and especially I don't understand why a long TCP backlog is an > indication of a need to run more workers - I mean, I probably have a backlog > because this host or another component on my network is lacking a resource > (CPU, RAM, IOPS, whatever). Why would I want to add more processes in this > scenario? Wouldn't it be better to increase my backlog, or add more of that > resource? > > Thanks, > - Yaniv > >
Hi Yaniv, explaining how sockets works and how concurrency is handled in your OS is a bit off-topic (and probably will require thousand of lines in the mail :) By the way, you do not have to think that preforking is a way to abuse your cores. Whenever your app is blocking (waiting for database data or some other external source) it will not be able to do something else. Adding processes will allows you to manage request when another one is blocked "waiting for something". The same applies to threads (with the difference that their memory is fully shared). On some server architecture (like apache1) this is the only way to operate (and this is why people often blame apache for being a memory hog, by default tit can prefork 256 workers) . As an example, think about an app requesting data to an external balanced http server. If one of the nodes of this http server is overloaded and will respond after 120 seconds, your app (if not preforked) will be completely blocked for 120 seconds (even if a second request could be served without problems as a new http node would respond). When you have no processes to accept requests, connections got enqueued in "socket backlog queue". So this is a good way to know if your app is overloaded. The more slot you add in your backlog queue the more clients can be enqueued (and will wait for cpu). Having a too much big backlog queue can be a problem on very loaded site as sometimes it is better to reject requests (or add new hardware nodes) on overload. Modern sysadmin rules suggest us to not leave resources unused (not used memory is wasted memory) so, the main idea of autoscaling is creating a pool of fixed resources that will be given to apps requiring them (that eventually will be reclaimed for other apps and so on). Finally, to answer your question: Yes, if you have a blocking app (lot of request on external resources, like db) and you have the memory for 20 workers, use them. On the other side, if you have a hello world app (non blocking app), you will get better result with 1 worker for process core. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
