<div dir="ltr">Dedicated and isolated infrastructure is a must if we want consistent performance numbers. If we can come up with a reasonable plan, I'd be happy to ask for resources. Even with dedicated infrastructure we would still have to keep in mind that it's a data point from a single provider that hopefully highlights a general trend about performance.<div><br></div><div>Here is a list of focus points as I see them so far:</div><div><br></div><div><ul><li>Dedicated hardware is a requirement in order to achieve somewhat consistent results</li><li>Tight loop micro benchmarks<br></li><li>Tests highlighting the performance cases we care about<br></li><li>The ability to determine a sane control<br></li><li>The ability to tests proposed patches, compare them to the control, and leave comments on reviews<br></li><li>Reproducible setup and test runner so that others can run these against a dedicated performance environment</li><li>Daily snapshots of performance published publicly (nice to have)<br></li></ul></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 3:16 PM, Brant Knudson <span dir="ltr"><<a href="mailto:blk@acm.org" target="_blank">blk@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jun 3, 2016 at 2:35 PM, Lance Bragstad <span dir="ltr"><<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>I have been curious about impact of providing performance feedback as part of the review process. From what I understand, keystone used to have a performance job that would run against proposed patches (I've only heard about it so someone else will have to keep me honest about its timeframe), but it sounds like it wasn't valued.</div><div><br></div></div></blockquote><div><br></div></span><div>We had a job running rally for a year (I think) that nobody ever looked at so we decided it was a waste and stopped running it.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I think revisiting this topic is valuable, but it raises a series of questions.</div><div><br></div><div>Initially it probably only makes sense to test a reasonable set of defaults. What do we want these defaults to be? Should they be determined by DevStack, openstack-ansible, or something else?</div><div><br></div></div></blockquote><div><br></div></span><div>A performance test is going to depend on the environment (the machines, disks, network, etc), the existing data (tokens, revocations, users, etc.), and the config (fernet, uuid, caching, etc.). If these aren't consistent between runs then the results are not going to be usable. (This is the problem with running rally on infra hardware.) If the data isn't realistic (1000s of tokens, etc.) then the results are going to be at best not useful or at worst misleading.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>What does the performance test criteria look like and where does it live? Does it just consist of running tempest?</div><div><br></div></div></blockquote><div><br></div></span><div>I don't think tempest is going to give us numbers that we're looking for for performance. I've seen a few scripts and have my own for testing performance of token validation, token creation, user creation, etc. which I think will do the exact tests we want and we can get the results formatted however we like.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>From a contributor and reviewer perspective, it would be nice to have the ability to compare performance results across patch sets. I understand that keeping all performance results for every patch for an extended period of time is unrealistic. Maybe we take a daily performance snapshot against master and use that to map performance patterns over time?</div><div><br></div></div></blockquote><div><br></div></span><div>Where are you planning to store the results?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Have any other projects implemented a similar workflow?<br></div><div><br></div><div>I'm open to suggestions and discussions because I can't imagine there aren't other folks out there interested in this type of pre-merge data points.</div><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Thanks! </div><span><font color="#888888"><div><br></div><div>Lance</div></font></span></div>
<br></blockquote><div><br></div></span><div><div>Since the performance numbers are going to be very dependent on the machines I think the only way this is going to work is if somebody's willing to set up dedicated hardware to run the tests on. If you're doing that then set it up to mimic how you deploy keystone, deploy the patch under test, run the performance tests, and report the results. I'd be fine with something like this commenting on keystone changes. None of this has to involve openstack infra. Gerrit has a REST API to get the current patches.</div><div><br></div><div>Everyone that's got performance requirements should do the same. Maybe I can get the group I'm in to try it sometime.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Brant</div></font></span></div><div><br></div></div>
</div></div>
<br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>