On Sat, Jun 18, 2011 at 1:40 PM, Roberto De Ioris <[email protected]> wrote: > > Il giorno 18/giu/2011, alle ore 18.44, Trey Long ha scritto: > >> You weren't kidding, this setup is quite a bit more complex to >> understand. I do have a few questions though. >> >> 1. What exactly is fastrouter and what is its job? > > > The fastrouter is a proxy between the webserver and all of your apps. > > It allows you to avoid choosing/configuring ports or domain name and > automatically adds load balancing and failover. > > In your case you would configure nginx to talk ONLY to the fastrouter on its > socket, then all of your apps will subscribe to the fastrouter > that automatically forward requests to them based on hostname (or some other > key you can set in nginx) > > Yann Malet of Lincoln Loop has a good document on their specific setup > (using Cherokee), you can read it to better understand the emperor+fastrouter > way: > > http://projects.unbit.it/uwsgi/attachment/wiki/Emperor/lincolnloop.pdf >
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. > >> 2. This setup will not prevent the overload of processes from the >> emperor correct? It seems like if there is a little bit of traffic all >> over the farm then there will be many processes active. > > > this point is not very clear to me, i suppose you prefer to have all of your > apps under a single process, but often this > is a dangerous approach as you will have no permission isolations between > apps and things like file descriptors will be shared by all of the apps. > > Most important you lose control on who is consuming what resource. In my particular use case the applications are mostly trusted but I do completely understand where you're coming from about process separation. As far as what I'm trying to accomplish, let me try to be clearer: If each vassal has 8 processes and 50 threads and I have 10 vassals a small stream of traffic to all applications is going to spawn a massive amount of processes and possibly overload the machine. 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? I am trying to achieve a configuration that can adapt to the requirements at hand. It seems like spawning the MAXIMUM number of processes/threads based on available CPU cores and letting all of the applications share this resource pool would achieve this. However, from your later comment it also sounds like the application/worker concepts are tightly coupled and an application cannot be reloaded independently without also killing the worker. > >> 3. Something very common in our applications is for a website to >> contain a *.hostname, will this still work? > > you need to add a server directive in nginx for each wildcard domain, but i > have already a patch that extends the fastrouter > with regexp support (via pcre) that could solve this task elegantly. > >> >> >> I think what I might do is just monitor the app files in my own >> process and issue a HUP when they change. Hopefully I can just dodge >> the memory issues from loading a bunch of applications at once for >> now. I will experiment with this example first though. > > before the emperor-era my suggestion was "grouping" apps in multiple > instances. > > For example app1 and app2 live in the same process and app3,app4 and app5 > live in another. > > This allows you to not totally lose control on resources. This is smart, if I have trusted or higher priority applications I can manually send them to another socket with a higher priority uWGSI daemon behind it. Currently I don't have that need, but I'll remember that. > >> >> >> My official feature request is to allow passing of a touch-reload and >> an idle command from nginx. >> For example: >> uwsgi_param UWSGI_TOUCH_RELOAD module; > > this is already available: If UWSGI_TOUGH_RELOAD is officially support I will try it again. This will solve half of my problem, however when I tried it the first time it didn't work for me. I'm sure I probably screwed up the config somewhere. > > http://projects.unbit.it/uwsgi/wiki/uWSGIVars > >> uwsgi_param UWSGI_IDLE 300; > > > this can be a problem, as you can reload a whole process and not the single > aps, > so even if checking if an app is not busy for ages is easy, the only action > we can trigger is reloading all of the apps in the same process. > > -- > 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
