From abc12279f774bafdc83e03234ef2bad679072a8b Mon Sep 17 00:00:00 2001 From: Kevin Benton Date: Thu, 26 Mar 2015 19:52:23 -0700 Subject: [PATCH] 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 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/neutron/db/models_v2.py b/neutron/db/models_v2.py index c05780039..b3109b5db 100644 --- a/neutron/db/models_v2.py +++ b/neutron/db/models_v2.py @@ -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): -- 2.45.2