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


Groups > comp.lang.python > #102853

Re: asyncio and blocking - an update

From "Frank Millman" <frank@chagford.com>
Newsgroups comp.lang.python
Subject Re: asyncio and blocking - an update
Date 2016-02-12 10:17 +0200
Message-ID <mailman.71.1455265073.22075.python-list@python.org> (permalink)
References (1 earlier) <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>

Show all headers | 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


Thread

Re: asyncio and blocking - an update "Frank Millman" <frank@chagford.com> - 2016-02-12 10:17 +0200

csiph-web