Fix performance regression adding rules to security groups
Sometime between liberty and pike, adding rules to SG's got
slow, and slower with every rule. Streamline the rule create path,
and get close to the old performance back.
Two performance fixes:
1. Get rid of an n^2 duplicate check, using a hash table instead,
on bulk creates. This is more memory intensive than the previous loop,
but usable far past where the other becomes too slow to be useful.
2. Use an object existence check in a few places where we do not
want to load all of the child rules.
Also squashed in:
Restore tenant_id check on security group rule adds to previous semantic
We switched from swapping the tenant_id in the context to explicitly
checking the db column. Switch back, and a test that checks for
not breaking this rather odd behavior. At least, until we decide
to fix it as a bug.
Co-Authored-By: William Hager <email address hidden>
Change-Id: I34e41a128f28211f2e7ab814a2611ce22620fcf3
Closes-bug: 1810563
(cherry picked from commit 2eb31f84c9a6c9fc6340819f756a7a82cbf395f3)
(squashed patch from commit bd4c291cdfb5a75976b1f846f6d7ca88d2d154e9)
Reviewed: https:/ /review. openstack. org/633145 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=f9cbd939b99 8f6b8d29c8d347d 1b9322c699825f
Committed: https:/
Submitter: Zuul
Branch: stable/pike
commit f9cbd939b998f6b 8d29c8d347d1b93 22c699825f
Author: Doug Wiegley <email address hidden>
Date: Fri Jan 4 14:55:29 2019 -0700
Fix performance regression adding rules to security groups
Sometime between liberty and pike, adding rules to SG's got
slow, and slower with every rule. Streamline the rule create path,
and get close to the old performance back.
Two performance fixes:
1. Get rid of an n^2 duplicate check, using a hash table instead,
on bulk creates. This is more memory intensive than the previous loop,
but usable far past where the other becomes too slow to be useful.
2. Use an object existence check in a few places where we do not
want to load all of the child rules.
Also squashed in:
Restore tenant_id check on security group rule adds to previous semantic
We switched from swapping the tenant_id in the context to explicitly
checking the db column. Switch back, and a test that checks for
not breaking this rather odd behavior. At least, until we decide
to fix it as a bug.
Co-Authored-By: William Hager <email address hidden> 1f2e7ab814a2611 ce22620fcf3 c6340819f756a7a 82cbf395f3) 976b1f846f6d7ca 88d2d154e9)
Change-Id: I34e41a128f2821
Closes-bug: 1810563
(cherry picked from commit 2eb31f84c9a6c9f
(squashed patch from commit bd4c291cdfb5a75