Reviewed: https://review.openstack.org/269892 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4398f14a9ab177c162d3267b1d2b0c7c50bb82a5 Submitter: Jenkins Branch: master
commit 4398f14a9ab177c162d3267b1d2b0c7c50bb82a5 Author: Ihar Hrachyshka <ihrac...@redhat.com> Date: Tue Jan 19 23:10:25 2016 +0100 Postpone heavy policy check for ports to later When a port is validated, we check for the user to be the owner of corresponding network, among other things. Sadly, this check requires a plugin call to fetch the network, which goes straight into the database. Now, if there are multiple ports to validate with current policy, and the user is not admin, we fetch the network for each port, f.e. making list operation on ports to scale badly. To avoid that, we should postpone OwnerCheck (tenant_id) based validations that rely on foreign keys, tenant_id:%(network:...)s, to as late as possible. It will make policy checks avoid hitting database in some cases, like when a port is owned by current user. Also, added some unit tests to avoid later regressions: DbOperationBoundMixin now passes user context into API calls. It allows us to trigger policy engine checks when executing listing operations. Change-Id: I99e0c4280b06d8ebab0aa8adc497662c995133ad Closes-Bug: #1513782 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1513782 Title: API response time degradation Status in neutron: Fix Released Bug description: We found response time degradation in list operations for network objects. Such degradation we found in our rally jobs. This job works in devstack with 'fake_virt' libvirt driver. One part of this job creates 200 servers with floating ip and lists them and their objects. I saw that 18.08.2015 response times was good [1] but 21.08.2015 they became bad [2]. Right now response times still bad [3]... I suggest that this is a neutron problem because we have several tests that measure different aspects. For example, listing of regions and images have same times as in the past. But degradation of addresses` listing is in ~ten times: was (for 200 servers): 0.719 seconds now (for 100 servers): 5.039 seconds subnets: 1.358 vs 5.606 network_interfaces: 1.292 vs 10.298 Also I've asked in mailing list [4] but there was no sensible answer... [1] http://logs.openstack.org/13/211613/6/experimental/ec2-api-rally-dsvm-fakevirt/fac263e/ [2] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/ [3] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/rally-plot/detailed.txt.gz [4] http://lists.openstack.org/pipermail/openstack-dev/2015-September/073577.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1513782/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp