Comment 4 for bug 1437131

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/juno)

Reviewed: https://review.openstack.org/168435
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fe59efd1d62ed3379851d4f438aeb12b3b2bff5c
Submitter: Jenkins
Branch: stable/juno

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)