commit fe59efd1d62ed3379851d4f438aeb12b3b2bff5c
Author: Kevin Benton <email address hidden>
Date: Thu Mar 26 19:52:23 2015 -0700
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
(cherry picked from commit abc12279f774bafdc83e03234ef2bad679072a8b)
Reviewed: https:/ /review. openstack. org/168435 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=fe59efd1d62 ed3379851d4f438 aeb12b3b2bff5c
Committed: https:/
Submitter: Jenkins
Branch: stable/juno
commit fe59efd1d62ed33 79851d4f438aeb1 2b3b2bff5c
Author: Kevin Benton <email address hidden>
Date: Thu Mar 26 19:52:23 2015 -0700
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: Ia94ce9437ad21e 4f21526ba84213f d673693db34 dc83e03234ef2ba d679072a8b)
Closes-Bug: #1437131
(cherry picked from commit abc12279f774baf