Excerpts from Vishvananda Ishaya's message of 2015-01-29 10:21:58 -0800: > > On Jan 29, 2015, at 8:57 AM, Roman Podoliaka <rpodoly...@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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
