]> review.fuel-infra Code Review - openstack-build/neutron-build.git/commit
Don't eagerly load ranges from IPAllocationPool
authorKevin Benton <blak111@gmail.com>
Fri, 27 Mar 2015 02:52:23 +0000 (19:52 -0700)
committerKevin Benton <blak111@gmail.com>
Fri, 27 Mar 2015 02:52:23 +0000 (19:52 -0700)
commitabc12279f774bafdc83e03234ef2bad679072a8b
treea7b3ad297cc56b4f9c13a1909d7842ed157eb1d1
parent5c6781a6f76a470ca67be7970981ebc46c62c70a
Don't eagerly load ranges from IPAllocationPool

The subnet object eagerly loads the IPAllocationPools
associated with it. Each of these was eagerly loading
the IPAvailabilityRange objects associated with it.
On a large subnet with lots of churn, this could be
thousands of records. All of these records were being
loaded for every call to get_subnet, which means all
get_subnets, get_networks, and so-on. icky

This patch changes the relationship between IPAllocationPool
and available_ranges to a 'select' load, so they won't be
loaded until referenced. On my test system with a subnet
that contained 10k ports, this changed the subnet-show time
from 4.7 seconds to 0.56 seconds.

There is no performance downside to this in the upstream
code. At the time of this patch, there were no references
to 'available_ranges' on an IPAllocationPool result. The
logic that deals with the available ranges queries them
explicitly using join statements.

Change-Id: Ia94ce9437ad21e4f21526ba84213fd673693db34
Closes-Bug: #1437131
neutron/db/models_v2.py