I tested with Eventlet and Gunicorn with Eventlet workers, and both can be made to work. I loaded the page in two web browsers concurrently rather than calling from the console, but I think I can assume that this is immaterial?
Eventlet monkey patching only works if it is called before any imports of the patched libraries happen, so it cannot just be dropped into anyserver.py as is, but it is trivial to write a script to use it. For Gunicorn, there is a bug in the gunicorn method (incidentally, it is also called gnuicorn) in anyserver.py (too many arguments given to Arbiter init) which stops it working at all. I could not find the docs I needed to fix it, so I wrote this in a file called web2py_eventlet.py: from eventlet import monkey_patch monkey_patch(all=True) import gluon.main app = gluon.main.wsgibase and ran gunicorn with gunicorn -w 1 -k eventlet web2py_eventlet:app it also works fine. It is possible to monkey patch psycopg to be always async as well, but I do not think this will work with web2py as the connection.commit() and connection.rollback() methods will not work as expected. That brings me to another problem. I wonder if it is worth bothering with an async web server, given that the database is going to require a thread or process per concurrent request anyway. Is there anyway around that? Does a request need to tie up a database connection while waiting for something else to happen? On Jun 23, 6:08 pm, Massimo Di Pierro <[email protected]> wrote: > The test is easy: > > def index(): > import time > from gluon import current > print current.request.uuid > sleep(10) > print current.request.uuid > return 'done!' > > call this action twice from console within less then 10 seconds from > each other what is the output? > if it looks > A > B > A > B > than the monkey patching is correct if it looks like > A > B > B > B > then it is not. If it looks like > A > A > B > B > then we are not testing right. A,B are uuids. > > massimo > > On Jun 23, 5:22 am, graeme <[email protected]> wrote: > > > > > > > > > Thanks for the reply. > > > So what anyserver.py does with gevent is not recommended? It calls > > monkey.patch_all() which patches threading to use green threads. > > > Is this something that ought to work but is just untested? web2py is > > pure python so the monkey patching should make thread locals into > > greenlet locals, right? If that is so, then is the testing something I > > could do myself, or does it need to be done by someone who knows the > > internals of web2py? > > > Graeme > > > On Jun 23, 8:10 am, Massimo Di Pierro <[email protected]> > > wrote: > > > > I am not sure this does not break the new internal web2py design that > > > uses thread locals. > > > I would not useasyncunless we have tested this more. > > > > Massimo > > > > On Jun 22, 6:44 pm, graeme <[email protected]> wrote: > > > > > I can see that anyserver.py uses monkey patching to make the standard > > > > library cooperative with gevent. > > > > > Could the same be done with eventlet and with Gunicorn (with eventlet, > > > > gevent or both)? > > > > > Eventlet has the advantages of being (AFAIK) pure python, and can > > > > monkey patch psycopg as well as the standard library. > > > > > Has anyone measured whether it is significantly more memory efficient > > > > to run web2py on green threads? > > > > > My use case is that I will have long running controllers (while > > > > fetching data from web services). I would like it to be memory > > > > efficient, but I am nt* looking for massive scalability or extreme > > > > speed. I do not want it to be trivial to DOS (so I need either threads > > > > or green threads to handle the long running controllers).
