No but I will now, ty! -- Brian Stajkowski Manager, Software Development US m: 702.575.7890 irc: ski e: brian.stajkow...@rackspace.com
On 12/8/16, 12:06 AM, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote: >Do you test with https://review.openstack.org/#/c/271830/ included? Would > >be nice to use a setup with the patch included as our new base. > >Brian Stajkowski <brian.stajkow...@rackspace.com> wrote: > >> 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.stajkow...@rackspace.com >> >> >> >> >> On 12/7/16, 3:38 AM, "John Davidge" <john.davi...@rackspace.com> wrote: >> >>> On 12/6/16, 6:06 PM, "Tidwell, Ryan" <ryan.tidw...@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 ab...@rackspace.com >>>and >>> delete the original message. Your cooperation is appreciated. >>> >>>________________________________________________________________________ >>>__ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >>_________________________________________________________________________ >>_ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
