More typical server for CPython

[sashahart]

The simple way gunicorn is used right now is more typical of local testing than production. When using CPython in a performance-conscious way, it is customary to serve using uwsgi or if using gunicorn, to have it use an optimized worker like gevent or meinheld. At any rate, these servers are designed to serve from behind something else, e.g. nginx (e.g. uwsgi using uwsgi_pass). This is common knowledge in the Python community.

All of these dependencies can be installed with 'pip install': gunicorn, gevent, uwsgi, meinheld, using CPython 2.7.

[tarekziade]

Adding Nginx is a good idea to enhance the pooling of the requests.

You also need to look at the nature of the app: currently the wsgi example is purely CPU-bound, since all it does is a json.dumps() and gets locked in a single CPU/worker when doing this (because of the GIL). So while using a client like ujson will improve the performances, I also think the app should do the sql calls so it can be compared.

What I would do:

• change the app so it does exactly like other apps.
• move to ujson - that'll speed up the json serialization.
• do the sql calls on the mysql DB using PyMySql which is 'green'.
• use gevent workers and monkey patch the socket module, this will make all sql calls async

[tarekziade]

notice that there will be 0 benefit to run gevent or meinheld for the json test since it's purely CPU-bound

[sashahart]

I guessed that the WSGI app in hello.py was supposed to just be a JSON serialization test and not a single-database-access test, I think there is no WSGI equivalent of the Django database test right now.

Perhaps it is for stupid reasons, but I see consistent, very significant request/s improvements locally with ab, against an app running on CPython, by not simply typing 'gunicorn -w $n whatever:app', just by using boring old techniques that are often done like telling gunicorn to use a different backend, or using uwsgi. I believe these kinds of things (or equivalent tuning in mod_wsgi, a deep subject) are typical practice for CPython developments. I would not have raised an issue if it were a matter of 1% or twiddling obscure and difficult parameters.
So I think it is worth looking into not doing this in the way that is currently in the repo.

[LadyMozzarella]

Closing this issue due to inactivity. A lot has changed in the repo and there are now several implementations for cpython. If you see this as something that needs to be addressed, reopen the issue. First commit from Mar 28, 2013 for reference: 7d8ac9406eb1d9071af978dd9cdb1e32c68aae45