<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 7/11/14, 7:26 PM, Carl Baldwin wrote:<br>
<span style="white-space: pre;">><br>
><br>
> On Jul 11, 2014 5:32 PM, "Vishvananda Ishaya"
<<a class="moz-txt-link-abbreviated" href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:vishvananda@gmail.com"><mailto:vishvananda@gmail.com></a>>
wrote:<br>
> ><br>
> > I have tried using pymysql in place of mysqldb and in
real world concurrency<br>
> > tests against cinder and nova it performs slower. I was
inspired by the mention<br>
> > of mysql-connector so I just tried that option instead.
Mysql-connector seems<br>
> > to be slightly slower as well, which leads me to believe
that the blocking inside of<br>
><br>
> Do you have some numbers? "Seems to be slightly slower"
doesn't really stand up as an argument against the numbers that
have been posted in this thread. <br>
><br>
> > sqlalchemy is not the main bottleneck across projects.<br>
> ><br>
> > Vish<br>
> ><br>
> > P.S. The performanace in all cases was abysmal, so
performance work definitely<br>
> > needs to be done, but just the guess that replacing our
mysql library is going to<br>
> > solve all of our performance problems appears to be
incorrect at first blush.<br>
><br>
> The motivation is still mostly deadlock relief but more
performance work should be done. I agree with you there. I'm
still hopeful for some improvement from this.<br>
</span><br>
<br>
To identify performance that's alleviated by async you have to
establish up front that IO blocking is the issue, which would entail
having code that's blazing fast until you start running it against
concurrent connections, at which point you can identify via
profiling that IO operations are being serialized. This is a very
specific issue.<br>
<br>
In contrast, to identify why some arbitrary openstack app is slow,
my bet is that async is often not the big issue. Every day I look
at openstack code and talk to people working on things, I see many
performance issues that have nothing to do with concurrency, and as
I detailed in my wiki page at
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy">https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy</a> there is a
long road to cleaning up all the excessive queries, hundreds of
unnecessary rows and columns being pulled over the network,
unindexed lookups, subquery joins, hammering of Python-intensive
operations (often due to the nature of OS apps as lots and lots of
tiny API calls) that can be cached. There's a clear path to tons
better performance documented there and most of it is not about
async - which means that successful async isn't going to solve all
those issues.<br>
<br>
</body>
</html>