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
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
