Open Stack

Excerpts from Vishvananda Ishaya's message of 2015-01-29 10:21:58 -0800:
> 
> On Jan 29, 2015, at 8:57 AM, Roman Podoliaka <rpodolyaka at mirantis.com> wrote:
> 
> > Jeremy,
> > 
> > I don't have exact numbers, so yeah, it's just an assumption based on
> > looking at the nova-api/scheduler logs with connection_debug set to
> > 100.
> > 
> > But that's a good point you are making here: it will be interesting to
> > see what difference enabling of PyMySQL will make for tempest/rally
> > workloads, rather than just running synthetic tests. I'm going to give
> > it a try on my devstack installation.
> 
> 
> FWIW I tested this a while ago on some perf tests on nova and cinder that we
> run internally and I found pymysql to be slower by about 10%. It appears that
> we were cpu bound in python more often than we were blocking talking to the
> db. I do recall someone doing a similar test in neutron saw some speedup,
> however. On our side we also exposed a few race conditions which made it less
> stable. We hit a few hard deadlocks in volume create IIRC. 
> 
> I don’t think switching is going to give us much benefit right away. We will
> need a few optimizations and bugfixes in other areas (particularly in our
> sqlalchemy usage) before we will derive any benefit from the switch.
> 

No magic bullets, right? I think we can all resolve this statement in
our heads though: "fast and never concurrent" will eventually lose to
"concurrent and potentially fast with optimizations."

The question is, how long does the hare (python-mysqldb) have to sleep
before the tortoise (PyMySQL) wins? Right now it's still a close race, but
if the tortoise even gains 10% speed, it likely becomes no contest at all.