> Hello Roberto,
>
> that strange but I got the same results. I checked twicely that
> patches correctly applied and compiled, but I don't see any difference
> in benchmark results? looks like bottleneck is somewhere else.
>
> the main problem that if we are going to keep active 100-200K
> connections - this can be an issue, but maybe we are already at some
> top limit, so maybe it's ok - I'am not sure.
>
> also, the main my question about dynamic mode. maybe we need just
> to set maximum limit and later create them dynamically with some step?
> so if free threads is less then 100 we are creating next 1000 threads
> or 2000 threads, if for last 10 minutes or 20 minutes - we have more
> than 2000 threads free we are closing them - upto 1000 free. so tuning
> will allow to change threads dynamically and performance, but in the
> same time all time have them already pre created. I see you have some
> stats - is current async threads value accessable in it? then it's
> pretty simple will be to scan this value periodically and to
> change async value dynamically with - external near running script.
>
> soon I'am going to do benchmark with commet threads so when
> 40-50-80-100K threads long running. right now I was available to get
> 49500 opened threads with gevent and 45000 threads with uwsgi with the
> same open file limit, not sure yet why so difference.
>
> and for sure will try any new patches if you have another ideas how to
> improve async performance.
>
> P.S: also if processes=2 and async=1000 - it will mean 2000
> threads created - right?
>

Cores not threads :) Yes, they will be 2000 and two of them will be
executed in parallel.

The other area that is O(n) is the timeout management. What happen if you
do not set timeout ?

Regarding dynamic allocation, i want to be sure that no part of the async
stack is O(n) after that we can start thinking about other-kind
optimizations

-- 
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to