> We currently run our Django app using uWSGI 1.2.3 in Emperor mode. Our > config looks like this: > >> root 17445 1 0 16:39 ? 00:00:00 >> /opt/nextdoor-ve/bin/uwsgi --log-syslog --master --die-on-term --emperor >> /etc/uwsgi >> root 17446 17445 0 16:39 ? 00:00:00 >> /opt/nextdoor-ve/bin/uwsgi --log-syslog --master --die-on-term --emperor >> /etc/uwsgi >> nextdoor 17447 17446 0 16:39 ? 00:00:01 >> /opt/nextdoor-ve/bin/uwsgi --ini frontend.ini >> nextdoor 17564 17447 17 16:51 ? 00:01:26 >> /opt/nextdoor-ve/bin/uwsgi --ini frontend.ini >> nextdoor 17565 17447 22 16:51 ? 00:01:49 >> /opt/nextdoor-ve/bin/uwsgi --ini frontend.ini >> nextdoor 17566 17447 14 16:51 ? 00:01:12 >> /opt/nextdoor-ve/bin/uwsgi --ini frontend.ini >> nextdoor 17567 17447 11 16:51 ? 00:00:58 >> /opt/nextdoor-ve/bin/uwsgi --ini frontend.ini > > >> [uwsgi] >> uid = nextdoor >> home = /opt/nextdoor-ve >> pythonpath = /home/nextdoor/src/nextdoor.com/apps/nextdoor >> env = NEXTDOOR_HOME=/home/nextdoor >> env = HOME=/home/nextdoor >> uwsgi-socket = /tmp/frontend.socket >> chmod-socket = 1 >> logdate = 1 >> optimize = 2 >> post-buffering = 1
[OT] post-buffering = 1 is a bit 'heavy' as it will create a file on the disk for each body bigger than 1 byte. [/OT] What you are describing is not the expected behaviour on standard preforking mode (you could experiment such requests loss using gevent or multithread, as multiple requests are concurrently managed by a worker). If you are not using some form of threaded or async mode i suspect you hit some 1.2 bug. Can you retry with 1.2.6 (latest stable for 1.2), 1.3 or 1.4 from github ? -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
