[Openstack-stable-maint] Neutron backports for security group performance

Ihar Hrachyshka ihrachys at redhat.com
Wed Oct 29 13:09:01 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29/10/14 14:00, Dolph Mathews wrote:
> 
> On Wed, Oct 29, 2014 at 5:23 AM, Ihar Hrachyshka
> <ihrachys at redhat.com <mailto:ihrachys at redhat.com>> wrote:
> 
> Hi all,
> 
> there is a series of Neutron backports in the Juno queue that are 
> intended to significantly improve service performance when
> handling security groups (one of the issues that are main pain
> points of current users):
> 
> - https://review.openstack.org/130101 -
> https://review.openstack.org/130098 -
> https://review.openstack.org/130100 -
> https://review.openstack.org/130097 -
> https://review.openstack.org/130105
> 
> The first four patches are optimizing db side (controller), while
> the last one is to avoid fetching security group rules by OVS agent
> when firewall is disabled.
> 
> AFAIK we don't generally backport performance improvements unless
> they are very significant (though I don't see anything written in
> stone that says so), but knowing that those patches fix pain
> hotspots in Neutron, and seem rather isolated, should we consider
> their inclusion?
> 
> Should we come up with some "official" rule on how we handle 
> performance enhancement backports?
> 
> 
>> I'm very much in favor of backporting known performance
>> improvements, but in my experience, not all "performance
>> improvements" actually improve performance, so I'd expect an
>> appropriate benchmark to demonstrate a real performance benefit
>> to coincide with the proposed patch.

Exactly. That's what I asked to elaborate on at:
https://review.openstack.org/#/c/130101/

Also, adding Kevin into CC to make sure he is aware of the discussion.

> 
>> For a hypothetical example, what seems like a clear cut
>> improvement in review 130098 (remove unused columns from a query)
>> *might* have an unforeseen side effect later on, where another
>> component doesn't have the data it needs, so it suddenly starts
>> issuing a new DB query to compensate. OpenStack is certainly
>> complicated enough that it's impossible to make accurate
>> assumptions about performance.
> 
> 
> 
> /Ihar
> 
> _______________________________________________ 
> Openstack-stable-maint mailing list 
> Openstack-stable-maint at lists.openstack.org 
> <mailto:Openstack-stable-maint at lists.openstack.org> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
> 
> 
> 
> 
> _______________________________________________ 
> Openstack-stable-maint mailing list 
> Openstack-stable-maint at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUUObtAAoJEC5aWaUY1u57UYwH/j+wjiydOXjA+lFi3l1Pbl5f
s7r4Ox6FCPPVoAKziKpygKRbHTrCTew4DcgOxZhmC9qoq+Rk8Q1WFMLlBQ+51Kjj
lj/72JiPenKvuZSl/E+9FsmWP7ReCCyUMYWiQS6wp6FAd5KpQMMgdjleUQWEAgjN
Y1M9kYVOmqnYHQy4oWJsV0Od2wFKFAGDKohLEzDocmTQFxcfkEeMSn3qJ4aOwkoz
KmTFKPGAGU8eTyYNAs3sHa0t9VFwvPoBg4EjMXBjkuoRxz+Nf/IPUZmrruXQ7LM6
ioXEUH3GdKQSCKWtYoFFI1QPpiTQSIalO6nURxUg0UldW6i5QwIX1LTz8GMG+TQ=
=JJq0
-----END PGP SIGNATURE-----



More information about the Openstack-stable-maint mailing list