yahoo-eng-team team mailing list archive

[OpenStack Infra <1513782@xxxxxxxxxxxxxxxxxx>]

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 <ihrachys@xxxxxxxxxx>
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