neutron get_subnet is slow

[Kevin Benton]

get_subnet becomes slow with large numbers of ip availability ranges.[1] This plagues anything else that calls get_subnet or get_subnets, which is lots of stuff.

1. $ time neutron subnet-show 9f4d3afa-5e13-4031-a24e-923adf36efb1
+-------------------+--------------------------------------------+
| Field | Value |
+-------------------+--------------------------------------------+
| allocation_pools | {"start": "0.0.0.2", "end": "0.0.255.253"} |
| cidr | 0.0.0.0/16 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 0.0.0.1 |
| host_routes | |
| id | 9f4d3afa-5e13-4031-a24e-923adf36efb1 |
| ip_version | 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | |
| network_id | b316a86e-1582-4b56-bbc1-d68dd6635ac9 |
| tenant_id | dcbae871d5bd419ea3c17cfb89e8a9c7 |
+-------------------+--------------------------------------------+

real 0m4.307s
user 0m0.353s
sys 0m0.074s

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/168214

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/168214
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=abc12279f774bafdc83e03234ef2bad679072a8b
Submitter: Jenkins
Branch: master

commit abc12279f774bafdc83e03234ef2bad679072a8b
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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/168435

[OpenStack Infra (hudson-openstack)]

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)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: neutron-pecan
Review: https://review.openstack.org/185072