Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #102853
| Path | csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail |
|---|---|
| From | "Frank Millman" <frank@chagford.com> |
| Newsgroups | comp.lang.python |
| Subject | Re: asyncio and blocking - an update |
| Date | Fri, 12 Feb 2016 10:17:34 +0200 |
| Lines | 43 |
| Message-ID | <mailman.71.1455265073.22075.python-list@python.org> (permalink) |
| References | <n9c4p3$gmp$1@ger.gmane.org> <n9h75i$ag1$1@ger.gmane.org> <CAPTjJmrVCkKAEevc9TW8FYYTnZgRUMPHectz+bD=DQRphXYTpw@mail.gmail.com> <n9ha5v$pb9$1@ger.gmane.org> <CAPTjJmor8dMv2TDtq8RHQgWeSAaZgAmxK9gFth=OojhidWHs3w@mail.gmail.com> <n9hjfp$ad7$1@ger.gmane.org> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; format=flowed; charset="iso-8859-1"; reply-type=response |
| Content-Transfer-Encoding | 8bit |
| X-Trace | news.uni-berlin.de eSld2OxZwn/NvxPwf6qw1QAMzZYWyn50KXwvCJUyvhmQ== |
| Return-Path | <python-python-list@m.gmane.org> |
| X-Original-To | python-list@python.org |
| Delivered-To | python-list@mail.python.org |
| X-Spam-Status | OK 0.001 |
| X-Spam-Evidence | '*H*': 1.00; '*S*': 0.00; 'concurrently': 0.07; 'correct.': 0.07; 'finished.': 0.07; 'app,': 0.09; 'concurrent': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'rows': 0.09; 'tasks,': 0.09; 'user.': 0.15; 'approaches.': 0.16; 'expected,': 0.16; 'operation.': 0.16; 'received:80.91.229.3': 0.16; 'received:io': 0.16; 'received:plane.gmane.org': 0.16; 'received:psf.io': 0.16; 'simulate': 0.16; 'obviously': 0.16; 'tests': 0.18; 'runs': 0.18; 'trying': 0.22; 'seems': 0.23; 'wrote': 0.23; 'header:In-Reply-To:1': 0.24; 'header:X-Complaints- To:1': 0.26; 'points': 0.27; "skip:' 10": 0.28; 'blocking': 0.29; 'concern': 0.29; 'second,': 0.29; 'subject:update': 0.29; 'starts': 0.29; 'themselves': 0.29; 'mention': 0.30; 'task': 0.30; 'seconds': 0.31; 'table': 0.32; 'embedded': 0.32; 'run': 0.33; 'environment,': 0.33; 'previous': 0.34; 'running': 0.34; 'next': 0.35; 'could': 0.35; 'i.e.': 0.35; 'tasks': 0.35; 'quite': 0.35; 'but': 0.36; 'should': 0.36; 'there': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'received:org': 0.37; 'someone': 0.38; 'does': 0.39; 'to:addr:python.org': 0.40; 'maximum': 0.61; '2000': 0.63; 'more': 0.63; 'within': 0.64; 'other.': 0.64; 'frank': 0.72; 'saw': 0.77; 'gut': 0.84; 'received,': 0.84; 'responding.': 0.84 |
| X-Injected-Via-Gmane | http://gmane.org/ |
| X-Gmane-NNTP-Posting-Host | 197.86.222.141 |
| In-Reply-To | <n9hjfp$ad7$1@ger.gmane.org> |
| X-MSMail-Priority | Normal |
| Importance | Normal |
| X-Newsreader | Microsoft Windows Live Mail 15.4.3502.922 |
| X-MimeOLE | Produced By Microsoft MimeOLE V15.4.3502.922 |
| X-BeenThere | python-list@python.org |
| X-Mailman-Version | 2.1.21rc2 |
| Precedence | list |
| List-Id | General discussion list for the Python programming language <python-list.python.org> |
| List-Unsubscribe | <https://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 | <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe> |
| Xref | csiph.com comp.lang.python:102853 |
Show key headers only | View raw
"Frank Millman" wrote in message news:n9hjfp$ad7$1@ger.gmane.org... > > However, my concern is not to maximise database performance, but to ensure > that in an asynchronous environment, one task does not block the others > from responding. My tests simulate a number of tasks running concurrently > and trying to access the database. Among other measurements, I track the > time that each database access commences. As I expected, tasks run with > 'run_in_executor' run sequentially, i.e. the next one only starts when the > previous one has finished. This is not because the tasks themselves are > sequential, but because 'fetchall()' is (I think) a blocking operation. > Conversely, with my approach, all the tasks start within a short time of > each other. Because I can process the rows as they are received, it seems > to give each task a fairer time allocation. Not to mention that there are > very likely to be other non-database tasks running concurrently, and they > should also be more responsive. > > It would be quite difficult to simulate all of this, so I confess that I > am relying on gut instinct at the moment. > It seems that my gut instinct was correct. Up to now my timing tests have been run independently of my app, but now I have embedded them so that I can run the tests while I am logged in as a user. I run a task every 10 seconds that runs 25 concurrent tasks, each reading a database table of about 2000 rows. Using run_in_executor() and cur.fetchall(), I experience delays of up to 2 seconds while the task is active. Using my approach, the maximum I saw was about a tenth of a second, and that is because I was looking for it - a normal user would not notice. Obviously the task took longer, but I can live with that trade-off. As I mentioned before, I could be using run_in_executor() in a naïve way, and there could be better approaches. But until someone points out a better way, I have nothing else to go on. Frank
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: asyncio and blocking - an update "Frank Millman" <frank@chagford.com> - 2016-02-12 10:17 +0200
csiph-web