> 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
