Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.029 X-Spam-Evidence: '*H*': 0.94; '*S*': 0.00; 'postgresql': 0.07; 'callback': 0.09; 'happen.': 0.09; 'postgresql,': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'runs': 0.10; 'api': 0.11; 'python': 0.11; 'wrote': 0.14; "'connection": 0.16; 'blocking': 0.16; 'complicated,': 0.16; 'concurrency': 0.16; 'concurrent': 0.16; 'materially': 0.16; 'obviously,': 0.16; 'reasonably': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'skip:n 70': 0.16; 'thread,': 0.16; 'threads,': 0.16; 'throughput': 0.16; 'users.': 0.18; 'bit': 0.19; 'trying': 0.19; 'appears': 0.22; 'driven': 0.24; 'focusing': 0.24; 'lets': 0.24; 'rid': 0.24; 'looks': 0.24; 'header:X -Complaints-To:1': 0.27; 'point': 0.28; 'getting': 0.31; 'requests': 0.31; '(although': 0.31; 'request,': 0.31; 'allows': 0.31; 'there.': 0.32; 'probably': 0.32; 'run': 0.32; 'quite': 0.32; 'received:co.za': 0.34; 'received:za': 0.34; 'could': 0.34; "can't": 0.35; 'connection': 0.35; 'etc': 0.35; 'but': 0.35; '5000': 0.36; 'ram': 0.36; 'should': 0.36; 'application': 0.37; 'so,': 0.37; 'too': 0.37; 'connections': 0.38; 'to:addr:python- list': 0.38; 'resource': 0.38; 'that,': 0.38; "couldn't": 0.39; 'to:addr:python.org': 0.39; 'received:org': 0.40; 'ensure': 0.60; 'problems.': 0.60; 'simple,': 0.60; 'slowly': 0.60; 'most': 0.60; 'back': 0.62; 'making': 0.63; 'such': 0.63; 'grab': 0.64; 'close': 0.67; 'frank': 0.68; 'lose': 0.68; 'received:41': 0.70; 'incoming': 0.72; 'allocation': 0.74; 'connection.': 0.74; 'gain': 0.79; 'interest.': 0.81; 'potentially': 0.81; 'asynchronous': 0.84; 'pools': 0.84; 'servers:': 0.84; 'dozen': 0.91; 'response,': 0.91; 'transactions': 0.91; 'clients,': 0.95; 'connection,': 0.95; 'hundred': 0.95 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: "Frank Millman" Subject: Re: Benefits of asyncio Date: Tue, 3 Jun 2014 13:09:29 +0200 References: <874n03t5t9.fsf@elektro.pacujo.net> <7x4n03dor0.fsf@ruckus.brouhaha.com> <878upe8poc.fsf@elektro.pacujo.net> X-Gmane-NNTP-Posting-Host: 41-135-99-235.dsl.mweb.co.za X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.4657 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 54 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1401793780 news.xs4all.nl 2902 [2001:888:2000:d::a6]:46512 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:72505 "Chris Angelico" wrote in message news:CAPTjJmqWkEStvrsrg30qjO+4TtLqfK9Q4GaByGovEw8NsdXzPg@mail.gmail.com... > > This works as long as your database is reasonably fast and close > (common case for a lot of web servers: DB runs on same computer as web > and application and etc servers). It's nice and simple, lets you use a > single database connection (although you should probably wrap it in a > try/finally to ensure that you roll back on any exception), and won't > materially damage throughput as long as you don't run into problems. > For a database driven web site, most of the I/O time will be waiting > for clients, not waiting for your database. > > Getting rid of those blocking database calls means having multiple > concurrent transactions on the database. Whether you go async or > threaded, this is going to happen. Unless your database lets you run > multiple simultaneous transactions on a single connection (I don't > think the Python DB API allows that, and I can't think of any DB > backends that support it, off hand), that means that every single > concurrency point needs its own database connection. With threads, you > could have a pool of (say) a dozen or so, one per thread, with each > one working synchronously; with asyncio, you'd have to have one for > every single incoming client request, or else faff around with > semaphores and resource pools and such manually. The throughput you > gain by making those asynchronous with callbacks is quite probably > destroyed by the throughput you lose in having too many simultaneous > connections to the database. I can't prove that, obviously, but I do > know that PostgreSQL requires up-front RAM allocation based on the > max_connections setting, and trying to support 5000 connections > started to get kinda stupid. > I am following this with interest. I still struggle to get my head around the concepts, but it is slowly coming clearer. Focusing on PostgreSQL, couldn't you do the following? PostgreSQL runs client/server (they call it front-end/back-end) over TCP/IP. psycopg2 appears to have some support for async communication with the back-end. I only skimmed the docs, and it looks a bit complicated, but it is there. So why not keep a 'connection pool', and for every potentially blocking request, grab a connection, set up a callback or a 'yield from' to wait for the response, and unblock. Provided the requests return quickly, I would have thought a hundred database connections could support thousands of users. Frank Millman