<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 29, 2014 at 5:23 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi all,<br>
<br>
there is a series of Neutron backports in the Juno queue that are<br>
intended to significantly improve service performance when handling<br>
security groups (one of the issues that are main pain points of<br>
current users):<br>
<br>
- - <a href="https://review.openstack.org/130101" target="_blank">https://review.openstack.org/130101</a><br>
- - <a href="https://review.openstack.org/130098" target="_blank">https://review.openstack.org/130098</a><br>
- - <a href="https://review.openstack.org/130100" target="_blank">https://review.openstack.org/130100</a><br>
- - <a href="https://review.openstack.org/130097" target="_blank">https://review.openstack.org/130097</a><br>
- - <a href="https://review.openstack.org/130105" target="_blank">https://review.openstack.org/130105</a><br>
<br>
The first four patches are optimizing db side (controller), while the<br>
last one is to avoid fetching security group rules by OVS agent when<br>
firewall is disabled.<br>
<br>
AFAIK we don't generally backport performance improvements unless they<br>
are very significant (though I don't see anything written in stone<br>
that says so), but knowing that those patches fix pain hotspots in<br>
Neutron, and seem rather isolated, should we consider their inclusion?<br>
<br>
Should we come up with some "official" rule on how we handle<br>
performance enhancement backports?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
<br>
iQEcBAEBCgAGBQJUUMAvAAoJEC5aWaUY1u57ZkMIAJmae7GdQ3rhRZVpUZkCGAUK<br>
7i2qPqjVh0Qu++kgcMmbM6YPnT4p//OuOAiU9ak8l46TWdeqw9cC0vsGO4Es4MKC<br>
rX8pAT/KBgX4FPzTGxhHBk8g5XpD9i6SutGfdFBmoFwj0eV8BAxNTD2A+hmM2ZHO<br>
QLBAcNFYhh/9QSnfpdx885z6M+iQ8n91oo1lqugZEdtmpNdrY2nW0ovFHTfj/9ku<br>
qznykok80JBNl1KO15Aaru3aHJUoj8/C8ek+UzLN0VP0W+H2zJQJVbGBny1BIVYm<br>
odvijGbxvq2rN90HbtUUqNwcM6Mfbc76fDT/agJo4hIDxXfvzsQpKY8iegiEiOc=<br>
=bBLb<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
Openstack-stable-maint mailing list<br>
<a href="mailto:Openstack-stable-maint@lists.openstack.org">Openstack-stable-maint@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint</a><br>
</blockquote></div><br></div></div>