<div dir="ltr">Lance, <div><br></div><div>It is amazing effort, I am wishing you good luck with Keystone team, however i faced some issues when I started similar effort<br></div><div>about 3 years ago with Rally. Here are some points, that are going to be very useful for you: <br><div><ol><li>I think that Keystone team doesn't care about performance & scalability at all</li><li>Keystone team ignored/discard all help from Rally team to make this effort successful <br></li><li>When Rally job started failing, because of introduced performance issues in Keystone, they decided to remove job<br></li><li>They blocked almost forever work on OSProfiler so we are blind and can't see where is the issue in code<br></li><li>They didn't help to develop any Rally plugin or even review the Rally test cases that we proposed to them</li></ol></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 10:45 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Brant Knudson's message of 2016-06-03 15:16:20 -0500:<br>
<span class="">> On Fri, Jun 3, 2016 at 2:35 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:<br>
><br>
> > Hey all,<br>
> ><br>
> > I have been curious about impact of providing performance feedback as part<br>
> > of the review process. From what I understand, keystone used to have a<br>
> > performance job that would run against proposed patches (I've only heard<br>
> > about it so someone else will have to keep me honest about its timeframe),<br>
> > but it sounds like it wasn't valued.<br>
> ><br>
> ><br>
> We had a job running rally for a year (I think) that nobody ever looked at<br>
> so we decided it was a waste and stopped running it.<br>
><br>
> > I think revisiting this topic is valuable, but it raises a series of<br>
> > questions.<br>
> ><br>
> > Initially it probably only makes sense to test a reasonable set of<br>
> > defaults. What do we want these defaults to be? Should they be determined<br>
> > by DevStack, openstack-ansible, or something else?<br>
> ><br>
> ><br>
> A performance test is going to depend on the environment (the machines,<br>
> disks, network, etc), the existing data (tokens, revocations, users, etc.),<br>
> and the config (fernet, uuid, caching, etc.). If these aren't consistent<br>
> between runs then the results are not going to be usable. (This is the<br>
> problem with running rally on infra hardware.) If the data isn't realistic<br>
> (1000s of tokens, etc.) then the results are going to be at best not useful<br>
> or at worst misleading.<br>
><br>
<br>
</span>That's why I started the counter-inspection spec:<br>
<br>
<a href="http://specs.openstack.org/openstack/qa-specs/specs/devstack/counter-inspection.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/qa-specs/specs/devstack/counter-inspection.html</a><br>
<br>
It just tries to count operations, and graph those. I've, unfortunately,<br>
been pulled off to other things of late, but I do intend to loop back<br>
and hit this hard over the next few months to try and get those graphs.<br>
<br>
What we'd get initially is just graphs of how many messages we push<br>
through RabbitMQ, and how many rows/queries/transactions we push through<br>
mysql. We may also want to add counters like how many API requests<br>
happened, and how many retries happen inside the code itself.<br>
<br>
There's a _TON_ we can do now to ensure that we know what the trends are<br>
when something gets "slow", so we can look for a gradual "death by 1000<br>
papercuts" trend or a hockey stick that can be tied to a particular<br>
commit.<br>
<span class=""><br>
> What does the performance test criteria look like and where does it live?<br>
> > Does it just consist of running tempest?<br>
> ><br>
> ><br>
> I don't think tempest is going to give us numbers that we're looking for<br>
> for performance. I've seen a few scripts and have my own for testing<br>
> performance of token validation, token creation, user creation, etc. which<br>
> I think will do the exact tests we want and we can get the results<br>
> formatted however we like.<br>
><br>
<br>
</span>Agreed that tempest will only give a limited view. Ideally one would<br>
also test things like "after we've booted 1000 vms, do we end up reading<br>
1000 more rows, or 1000 * 1000 more rows.<br>
<span class=""><br>
> From a contributor and reviewer perspective, it would be nice to have the<br>
> > ability to compare performance results across patch sets. I understand that<br>
> > keeping all performance results for every patch for an extended period of<br>
> > time is unrealistic. Maybe we take a daily performance snapshot against<br>
> > master and use that to map performance patterns over time?<br>
> ><br>
> ><br>
> Where are you planning to store the results?<br>
><br>
<br>
</span>Infra has a graphite/statsd cluster which is made for collecting metrics<br>
on tests. It might need to be expanded a bit, but it should be<br>
relatively cheap to do so given the benefit of having some of these<br>
numbers.<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>