<p dir="ltr"><br>
On Jun 3, 2016 13:16, "Brant Knudson" <<a href="mailto:blk@acm.org">blk@acm.org</a>> wrote:<br>
><br>
><br>
><br>
> 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 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.<br>
>><br>
><br>
> 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.<br>
>  <br>
>><br>
>> I think revisiting this topic is valuable, but it raises a series of questions.<br>
>><br>
>> 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?<br>
>><br>
><br>
> 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.<br>
><br>
>> What does the performance test criteria look like and where does it live? 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 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.<br>
><br>
>> 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?<br>
>><br>
><br>
> Where are you planning to store the results?<br>
>  <br>
>><br>
>> Have any other projects implemented a similar workflow?<br>
>><br>
>> 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.<br>
>>  <br>
>><br>
>> Thanks! <br>
>><br>
>> Lance<br>
>><br>
><br>
> 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.<br>
><br>
> Everyone that's got performance requirements should do the same. Maybe I can get the group I'm in to try it sometime.<br>
><br>
> - Brant<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
></p>
<p dir="ltr">You have outlined everything I was asking for fr rally as a useful metric, but simply getting the resources was a problem. </p>
<p dir="ltr">Unfortunately I have not seen anyone willing to offer these dedicated resources and/or reporting the delta over time or per patchset. </p>
<p dir="ltr">There is only so much we can do without consistent / reliably the same test environments.</p>
<p dir="ltr">I would be very happy to see this type of testing consistently reported especially if it mimics real workloads as well as synthetic like rally/what Matt and Dolph use. </p>
<p dir="ltr">--Morgan</p>