<div dir="ltr">+1<div><br></div><div>An obvious challenge is stabilizing external variables, but they're all solvable problems. We especially need hardware performance and network performance to be consistent across test runs. That likely means dedicated hardware, and a local copy of any content being sync'd. We should consider imposing a limit on bandwidth to the local content.</div><div><br></div><div><div>Some low-priority nice-to-haves for sanity-checking:</div><div>- start each run with a quick pure disk benchmark to ensure disk performance hasn't changed</div><div>- also consider a pure database performance benchmark as a quick way to identify if its performance has changed</div></div><div><br></div><div>An alternative to controlling these variable over a long period of time; any time a new version is ready for testing, re-run benchmarks of all versions you're interested in on whatever hardware is available at the time.</div><div><br></div><div>Is one of those approaches a better fit than the other for lucene?</div><div><br></div><div>Michael</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 12:11 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You know what's great? Knowing how code changes affect performance of a<br>
software project over time. To use an example from a completely separate<br>
project, here are performance benchmarks published by the Lucene<br>
project[0]. Click on the links in the "Results" section of that page to<br>
see the graphs. We could do the same thing but for Pulp.<br>
<br>
We need to plan this in more detail, but as a starting point, we could<br>
do the following for rpm content in particular.<br>
<br>
-Fresh metadata runtime of a large repo sync<br>
-Re-sync metadata runtime of a large repo sync with no packages modified<br>
<br>
-Fresh package download and associate runtime of a large repo sync<br>
-Re-sync package download and associate runtime of a large repo sync<br>
<br>
-Copy of 50k rpms from one repo to another without depsolve<br>
-Copy of 50k rpms from one repo to another with depsolve<br>
<br>
-Search performance using a simple Criteria filter<br>
<br>
-Fresh publish runtime of a large repo<br>
-Incremental (second) publish runtime of a large repo<br>
<br>
If you like this idea please +1 it via the mailing list and or give<br>
suggestions. Once we've got some support and/or ideas we can put it in<br>
<a href="http://pulp.plan.io" rel="noreferrer" target="_blank">pulp.plan.io</a>.<br>
<br>
[0]: <a href="https://people.apache.org/~mikemccand/lucenebench/" rel="noreferrer" target="_blank">https://people.apache.org/~mikemccand/lucenebench/</a><br>
<br>
-Brian<br>
<br>
_______________________________________________<br>
Pulp-list mailing list<br>
<a href="mailto:Pulp-list@redhat.com">Pulp-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-list</a><br>
</blockquote></div><br></div>