<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 3, 2016 at 1: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>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>What does the performance test criteria look like and where does it live? Does it just consist of running tempest?</div></div></blockquote><div><br></div><div>Keystone especially has some calls that are used 1000x or more relative to others and so I'd be more concerned about them. For me this is token validation #1 and token creation #2. Tempest checks them of course but might be too coarse? There are token benchmarks like the ones Dolph and I use, they are don't mimic a real work flow.  Something to consider.</div><div><br></div><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><br></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></blockquote><div><br></div><div>Having some time series data captured would be super useful. Could we have daily charts stored indefinitely?</div><div><br></div><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><br>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>Thanks! </div><span><font color="#888888"><div><br></div><div>Lance</div></font></span></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></div>