[openstack-dev] [neutron] trunk api performance and scale measurments

Brian Stajkowski Brian.Stajkowski at rackspace.com
Wed Dec 7 20:19:15 UTC 2016


Yes, this actually has to do with the policy check on any list of objects,
including ports.  The patch has to do with bypassing this individual
object check for get and delete as the individual attribute checks are
bypassed. The mentality is, if you have a list of objects with a base
action of get_ports, you are checking each object against the base action,
so why check every object.  But, I¹m looking for someone to say, yes there
is a reason and this is why.  Other than that, this cuts the response time
in half, but I¹m getting weird test failures with 3 tests as they are
related to a query count check, so some challenges.
--
Brian Stajkowski

Manager, Software Development ­ US
m: 702.575.7890
irc: ski
e: brian.stajkowski at rackspace.com




On 12/7/16, 3:38 AM, "John Davidge" <John.Davidge at rackspace.com> wrote:

>On 12/6/16, 6:06 PM, "Tidwell, Ryan" <ryan.tidwell at hpe.com> wrote:
>
>>
>>I failed to make much mention of it in previous write-ups, but I also
>>encountered scale issues with listing ports after a certain threshold. I
>>haven¹t gone back
>> to identify where the tipping point is, but I did notice that Horizon
>>began to really bog down as I added ports to the system. On the surface
>>it didn¹t seem to matter whether these ports were used as subports or
>>not, the sheer volume of ports added to the
>> system seemed to cause both Horizon and more importantly GET on
>>v2.0/ports to really bog down.
>>
>>-Ryan
>
>Could this be related to https://bugs.launchpad.net/neutron/+bug/1611626 ?
>
>John
>
>
>________________________________
>Rackspace Limited is a company registered in England & Wales (company
>registered number 03897010) whose registered office is at 5 Millington
>Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
>policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This
>e-mail message may contain confidential or privileged information
>intended for the recipient. Any dissemination, distribution or copying of
>the enclosed material is prohibited. If you receive this transmission in
>error, please notify us immediately by e-mail at abuse at rackspace.com and
>delete the original message. Your cooperation is appreciated.
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list