> Hello Roberto, > > thank you very much! > > here is working version with psycopg2 pool and it's realy async - > http://pastebin.com/JuEL4tFy > > but seems you meant some other way of pooling connections, right? > could you explain please with little more details, as current version > connections limited to amount of pool threads (50 here). but in this > schema even better not to use pgpool, but you need just to get/put > conn as fast as possible after each request. > > postgresql connect is very expensive, even when you connect to > pgpool/pgbouncer. > > so even django is better to use with modified psycopg2 adapter, what > will use psycop2.pool >
My idea is more (and more) raw of this one. I will open 1*cores connections (yes in your case thousand of opened connections) at worker startup to a pgpool server(or whatever pooling system you want). In this way the only part that must "wait" is the real postgresql server. With limited threadedpool embedded in your app, if you got 51 connections you will start waiting for completion of past requests. After yoy have setup all the connections, you will in your callable with something like this: # select connection connection = async_connections[env['uwsgi.core']] # do the query No need to load balance, or wait for availability. You will always get a file descriptor that will pass your query to the real pg servers (and eventually will wait only here) Beware of the uwsgi.core variable, it is exported only in 0.9.7-dev, but adding to 0.9.6 is very easy and fast (one line of code) By the way if you are using query most for reading i suggest you to look at the postgresql 9.x replica system (so you can distribute load). I found it very reliable, elegant and easy to use. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
