0

We are running our python app behind nginx. First we used uWSGI, because it is fast, reliable and easy to deploy. Next, as the number of simultaneous clients (using server-sent events/eventstream) increased, we have partially switched the app to gunicorn+gevent.

Currently, the app is served like this:

  • statics is handled by nginx directly;
  • short requests (REST API) is handled by uWSGI (nginx<->uwsgi connected via unix socket)
  • long requests (server-sent events) are handled by gunicorn+gevent (and nginx acts as a rev proxy)

Should we stay with this setup or are there any reasons for switching from uWSGI to gunicorn?

saabeilin
  • 409
  • 1
  • 4
  • 11

1 Answers1

1

It really depends on how much of the uWSGI features are part of your infrastructure. One of the purposes of WSGI is allowing easy move from one adapter to another. If you use uWSGI only for the "WSGI" part you can move to gunicorn without problems.

Having said that, you should take in account that the uWSGI gevent support is really powerful and highly integrated with the uWSGI api (once you load the gevent plugin, all of the blocking internals of the server are hooked with gevent primitives), so maybe you can consider it (in addition to this uWSGI offloading allows you to move requests from one instance to another without blocking the frontend worker, so your rest api can be used as a "proxy with more logic")

roberto
  • 1,812
  • 12
  • 8
  • Hmm, I should investigate uWSGI gevent support then. It seems that uWSGI overhead should be lesser then gunicorn's (because of using unix-sockets to communicate with upstream and more efficient protocol). The only reason for switching to gunicorn was using gevent trasparently. – saabeilin Mar 13 '14 at 05:20
  • roberto, I tried uWSGI+gevent. It runs *very* fast, but it never releases connections so I get `[DANGER] async queue is full` in uWSGI logs and no new connections served until uWSGI restart. – saabeilin Mar 14 '14 at 06:29
  • connections are released when the client disconnect. Maybe you have configured something wrong, but generally you create thousand of gevent cores, so unless you have thousand of concurrent customers you should not have problems. For example --gevent 4000 will allows you to create up to 4000 greenlet (one per client) – roberto Mar 14 '14 at 11:52
  • roberto, I know it *should*, but it seems it does not. I wonder what whouls I check twice? – saabeilin Mar 17 '14 at 10:50