Things I would like to see:
* weighted least connection algorithm in FastRouter instead of current WRR
BUT
* when using FastRouter and many vassals sharing just few servers
connection count is not the best indicator of whenever the physical
server is loaded or not, one app might have just few connections open
to node A, while other apps are very loaded on that node. From
FastRouter perspecive: there are many keys (domains/apps) pointing to
sockets on the same server, one FR key connection count will show that
the server is idle, others will show that it's very loaded, FR makes
decision on where to route next request by only looking at local (key)
stats, but this information is only valid for that key, not for the
server as whole, so it might make suboptimal decisions.
We could deal with that by:
a) subscription subsystem could send unique app ID along with domain
list and FR would use global connection stats for all domain keys with
given app id, so we would have two dictionaries in FastRouter:
1 - one for backend node statistics ('nodes' section in each subscription)
2 - one for domain statistics "hits" key as it is right now and for key=>nodes
This essentially means that "nodes" key from every subscription should
be globalized instead of repeating it for every subscription.
b) would could move it a step further and extract IP from every
subscription also store dict with per IP stats, this could be used for
per node statistics so that if one node is overloaded with requests
than all apps might use this information and route requests elsewhere.
c) we could also calculate each server load (unix load, average cpu
usage for last N secs, where N == subscription interval, memory usage,
or stuff like that, but math here could be tricky, maybe just unix 1
minute load value would be best choice), we could call that stress and
use that during weight calculation, so that heavily loaded nodes would
get less requests even if the app running on that server is not
loaded. But I don't think it's neede, first of all emperor itself
would need to calculate this, otherwise every vassal would need to do
this, and since this would be global information in FR, it would be
updated constantly. a) looks like a better idea to me
* FastRouter stats with multiple FR processes - currently they are
only calculated by first process, I would vote for per process stat
socket, each stats should contain a key with list of all FR stat
sockets open, for FR with 3 processes and first stat socket listening
on 2080 it would be something like this:
{
"version":"1.3-rc3",
"stats": [":2080", ":2081", ":2082"]
[...]
}
This way I would read 'stats' key from first stat socket and I would
fetch all other stat sockets data in loop.
* ability to set different loggers for access logs / error logs /
everything else (http://projects.unbit.it/uwsgi/ticket/74)
* http://projects.unbit.it/uwsgi/ticket/122
* http://projects.unbit.it/uwsgi/ticket/128
2012/9/22 Łukasz Mierzwa <[email protected]>:
> Any plans or roadmap for 1.4?
>
> --
> Łukasz Mierzwa
--
Łukasz Mierzwa
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
