[openstack-dev] [nova] entrypoint slowness

Doug Hellmann doug.hellmann at dreamhost.com
Tue Oct 30 23:07:21 UTC 2012


On Tue, Oct 30, 2012 at 6:44 PM, Sean Dague <sdague at linux.vnet.ibm.com>wrote:

> The review to land the first entrypoints switch over in nova passed
> through review and hit jenkins this afternoon -
> https://review.openstack.org/#**/c/11027/<https://review.openstack.org/#/c/11027/>and Jenkins failed it on a timeout (exceeded 30 minutes to run).
>
> Clark helpfully suggested that the patch might actually have had a
> performance impact, so I've been collecting data, and it did.
>
> On a decent blade with a spinning disk.
>
> Before the change the nova unit tests are running: ~385s (385.158s
> , 386.089s on two runs to ensure no cache effects).
>
> After that change the nova unit tests are running: ~920s (919.561s,
> 922.514s)
>
>
> 2.3 times slower.
>
>
> On my laptop (SSD) the effect is there, but not quite as dramatic: ~450s
> vs ~600s.
>
> So only 30% slower.
>
>
> While I get that in production, the class loading will disappear in the
> noise, that huge hit on the unit tests seems really problematic from a
> developer point of view. And a big problem from a CI perspective. Anyone
> have ideas on why this is such a huge hit, or thoughts on how to mitigate
> it?


I haven't profiled it, but my guess is that the extra time is from scanning
the entrypoints registry. That would, as you say, hardly matter when it is
only done once on startup. Perhaps we need to cache driver loaded from the
config outside of the manager (?) instance where it is used to avoid having
to rescan the registry each time the tests set up the manager.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121030/6e6bbe2a/attachment.html>


More information about the OpenStack-dev mailing list