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
This commit is contained in:
Kevin Benton 2015-03-26 19:52:23 -07:00
parent 5c6781a6f7
commit abc12279f7
1 changed files with 1 additions and 1 deletions

View File

@ -87,7 +87,7 @@ class IPAllocationPool(model_base.BASEV2, HasId):
last_ip = sa.Column(sa.String(64), nullable=False)
available_ranges = orm.relationship(IPAvailabilityRange,
backref='ipallocationpool',
lazy="joined",
lazy="select",
cascade='all, delete-orphan')
def __repr__(self):