<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2016 at 08:07, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 12/05/2016 10:59 AM, Bence Romsics wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
I measured how the new trunk API scales with lots of subports. You can<br>
find the results here:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling" rel="noreferrer" target="_blank">https://wiki.openstack.org/wik<wbr>i/Neutron_Trunk_API_Performanc<wbr>e_and_Scaling</a><br>
<br>
Hope you find it useful. There are several open ends, let me know if<br>
you're interested in following up some of them.<br>
</blockquote>
<br></span>
Great info in there, Ben, thanks very much for sharing!</blockquote><div><br></div><div>Bence,</div><div><br></div><div>Thanks for the wealth of information provided, I was looking forward to it! The results of the experimentation campaign makes me somewhat confident that trunk feature design is solid, or at least that is what it looks like! I'll look into why there is a penalty on port-list, because that's surprising for me too.</div><div><br></div><div>I also know that the QE team internally at HPE has done some perf testing (though I don't have results publicly available yet), but what I can share at this point is:</div><div><ul><li>They also disabled l2pop to push the boundaries of trunk deployments;</li><li>They disabled OVS firewall (though for reasons orthogonal to scalability limits introduced by the functionality);</li><li>They flipped back to ovsctl interface, as it turned out to be one of components that introduced some <b>penalty</b>. Since you use native interface, it'd be nice to see what happens if you flipped this switch too;</li><li>RPC timeout of 300.</li></ul>On a testbed of 3 controllers and 7 computes, this is at high level what they found out the following:</div><div><ul><li>100 trunks, with 1900 subports took about 30 mins with no errors;<br></li><li>500 subports take about 1 min to bind to a trunk;<br></li><li>Booting a VM on trunk with 100 subports takes as little as 15 seconds to successful ping. Trunk goes from BUILD -> ACTIVE within 60 seconds of booting the VM;</li><li>Scaling to 700 VM's incrementally on trunks with 100 initial subports is constant (e.g. booting time stays set at ~15 seconds).</li></ul>I believe Ryan Tidwell may have more on this.<br></div><div><br></div><div>Cheers,</div><div>Armando</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_4375657933605346031HOEnZb"><font color="#888888"><br>
<br>
-jay</font></span><div class="gmail-m_4375657933605346031HOEnZb"><div class="gmail-m_4375657933605346031h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>