Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #28204

Async client for PostgreSQL?

Path csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!newsfeed.eweka.nl!eweka.nl!feeder3.eweka.nl!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <gandalf@shopzeus.com>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.031
X-Spam-Evidence '*H*': 0.94; '*S*': 0.00; 'cache': 0.05; 'postgresql': 0.07; 'problem:': 0.07; 'suppose': 0.07; 'python': 0.09; 'blocking': 0.09; 'handler,': 0.09; 'objects.': 0.09; 'stored': 0.10; 'def': 0.10; 'extension': 0.13; 'resulting': 0.13; '(python)': 0.16; '1sec': 0.16; 'async': 0.16; 'query.': 0.16; 'skip:p 70': 0.16; 'threads': 0.16; 'thanks,': 0.18; 'memory': 0.18; 'requests': 0.18; 'amounts': 0.22; 'connected': 0.24; 'header:User-Agent:1': 0.26; 'looks': 0.26; '(as': 0.27; 'this?': 0.28; 'run': 0.28; 'email name:': 0.29; 'i/o': 0.29; 'objects': 0.29; 'class': 0.29; 'compatible': 0.30; 'running': 0.32; 'skip:s 30': 0.33; 'like:': 0.33; 'problem': 0.33; 'to:addr:python-list': 0.33; '(with': 0.33; 'times.': 0.33; 'server': 0.35; 'data,': 0.35; 'doing': 0.35; 'received:192.168.0': 0.35; 'subject:?': 0.35; 'something': 0.35; 'there': 0.35; 'but': 0.36; 'skip:m 40': 0.36; 'client': 0.36; 'too': 0.36; 'possible': 0.37; 'option': 0.37; 'why': 0.37; 'store': 0.38; 'object': 0.38; 'skip:o 20': 0.38; 'to:addr:python.org': 0.39; 'received:192': 0.39; 'short': 0.39; 'received:192.168': 0.40; 'end': 0.40; 'most': 0.61; 'high': 0.61; 'more.': 0.62; 'received:62': 0.62; 'time,': 0.62; 'is.': 0.62; 'relatively': 0.62; 'more': 0.63; 'decided': 0.65; 'state,': 0.65; 'theoretical': 0.65; 'biggest': 0.71; '100': 0.78; 'low': 0.83; '(web': 0.84; 'received:192.168.0.101': 0.84; 'received:192.168.13': 0.84; 'received:62.179': 0.84; 'received:62.179.121': 0.84; 'received:upcmail.net': 0.84; '(running': 0.91; 'faster.': 0.91
X-SourceIP 89.134.225.226
Date Sat, 01 Sep 2012 07:17:09 +0200
From Laszlo Nagy <gandalf@shopzeus.com>
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version 1.0
To python-list@python.org
Subject Async client for PostgreSQL?
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.15
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.24.1346476638.27098.python-list@python.org> (permalink)
Lines 49
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1346476638 news.xs4all.nl 6858 [2001:888:2000:d::a6]:43931
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:28204

Show key headers only | View raw


Is there any extension for Python that can do async I/O for PostgreSQL 
with tornadoweb's ioloop?

Something like:

class MainHandler(tornado.web.RequestHandler):
     @tornado.web.asynchronous
     def get(self):
	pg_connection.(long_taking_query_sql,params,callback=self.on_query_opened)

     def on_query_opened(self, query):
         self.write(process_rows(query))
         self.finish()



What would be an alternative?

The theoretical problem: suppose there are 100 clients (web browsers) 
connected to the server with keep alive connections. They are doing 
long-polls and they are also sending/receiving events (with short 
response times). Each web browser has an associated state stored on the 
server side, in the memory (as an object tree). The state is bound to 
the client with a session id. Most requests will have to be responded 
with small amounts of data, calculated from the session state, or 
queried from the database. Most database queries are simple, running for 
about 100msec. But a few of them will run for 1sec or more. Number of 
requests ending in database queries is relatively low (10/sec). Other 
requests can be responded must faster.  but they are much more frequent 
(100/sec, that is. 1 request/sec/client).  There is a big global cache 
full of (Python) objects. Their purpose is to reduce the number of 
database queries. These objects in the global cache are emitting events 
to other objects found in the client sessions. Generally, it is not 
possible to tell what request will end in a database query.

Multi-threading is not an option because number of clients is too high 
(running 100 threads is not good). This is why I decided to use anyc 
I/O. Tornadoweb looks good for most requirements: async i/o, store 
session state in objects etc. The biggest problem is that psycopg is not 
compatible with this model. If I use blocking I/O calls inside a request 
handler, then they will block all other requests most of the time, 
resulting in slow response times.

What would be a good solution for this?

Thanks,

    Laszlo

Back to comp.lang.python | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Async client for PostgreSQL? Laszlo Nagy <gandalf@shopzeus.com> - 2012-09-01 07:17 +0200
  Re: Async client for PostgreSQL? jwp <james.pye@gmail.com> - 2012-09-01 16:57 -0700
  Re: Async client for PostgreSQL? jwp <james.pye@gmail.com> - 2012-09-01 16:57 -0700

csiph-web