EDIT: it seems that bug #305 is fixed in latest 1.9.12 tarball so no need to patch it.
2013/6/5 Łukasz Mierzwa <[email protected]> > I did some tests with 1.9.12 simulating big responses and enough > concurrent connections to fill the queue. It clearly shows the advantage of > offload transformation. Workers push responses to offload engine and can > process new requests right away, this keeps backlog queue low at all times > (without offload I get a lot of "*** uWSGI listen queue of socket 3 full > !!! (11/10) ***" messages), response times are also lower since client > request doesn't need to wait before being processed. > > https://gist.github.com/prymitive/5712706 > > If anyone wants to try this be sure to use current master or apply > https://github.com/unbit/uwsgi/commit/0f397eeb55532296b3bcddb9148bc5b6fa8346f2 > on > top of 1.9.12 or it will eat up disk space (see > https://github.com/unbit/uwsgi/issues/305). > > > 2013/6/3 Łukasz Mierzwa <[email protected]> > >> I've just tested to see if offload threads are really async as advertised >> and it seems they are, great ;) >> >> What I've done (zero is 1GB file with zeros): >> >> $ uwsgi --http :8080 --static-map="/zero=zero" --stats :4444 >> --offload-threads 2 >> $ ab -c 10 -n 100 http://localhost:8080/zero >> >> With only 1 worker and 2 offload threads I had 10 concurrent connections >> (not queued but running). >> >> >> 2013/6/3 Roberto De Ioris <[email protected]> >> >>> >>> > I'll give it a try once 1.9.12 is out. >>> > >>> > AFAIK uWSGI is blocking and this is the cause of offload threads, this >>> is >>> > fine for dynamic requests that needs to run app code, but it also means >>> > that uWSGI will probably do worse that lighttpd or nginx in real world >>> > contest with serving static files under a lot of load and few thousands >>> > client connections. AFAIK both lighttpd and nginx are asynchronous. It >>> > isn't big issue since we can put uWSGI behind nginx and use it only for >>> > non-static requests, but since HTTP frontend is getting more features I >>> > wonder what's the goal here, is uWSGI intended to be as fast as others >>> (or >>> > maybe it is already), or nginx will always be required when maximum >>> > possible performance is required? >>> >>> >>> Since 1.9 it is no more blocking, each write must end in --socket-timeout >>> and if you enable a coroutine engine (like ugreen or coroae or gevent or >>> ...) it will automatically start to manage another request. >>> >>> Offloading is a way to free "cores" (it could be a worker, a thread a >>> coroutine...) delegating common task to a pool of threads that can manage >>> them without using too much resources (even coroutines are a finite >>> resource while offloading is only limited by file descriptor and memory, >>> and each offload task consume only 128 bytes) >>> >>> So speaking at higher level, offload threads can be seen as a little >>> nginx/lighttpd embedded in uWSGI that can do simple task using all of >>> your >>> cpu cores) >>> >>> I like to compare offload threads with hardware DMA, it can do only >>> simple >>> tasks (transfer memory) freeing the CPU from them. >>> >>> Having said that, speed in serving static is better (even if probably we >>> talk about microseconds difference) in pure-webservers as uWSGI need to >>> be >>> customizable for very specific uses (and this has a cost). >>> >>> I suppose when you start adding caching of path resolutions and similar >>> micro-optimizations you can build a uWSGI file-server faster than the >>> others, but it requires a very deep knowledge of your specific case, so >>> for "general-purpose" serving, a pure-webserver is a better bet. >>> >>> >>> Obviously this is the current status, i do not know what will happen >>> next :) >>> >>> -- >>> Roberto De Ioris >>> http://unbit.it >>> _______________________________________________ >>> uWSGI mailing list >>> [email protected] >>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >>> >> >> >> >> -- >> Łukasz Mierzwa >> > > > > -- > Łukasz Mierzwa > -- Łukasz Mierzwa
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
