<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Flavio, thanks for the input<br></div><div class="gmail_quote"><br>On Wed, Apr 24, 2013 at 6:44 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 23/04/13 17:37 -0500, Ray Pekowski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  I would like to start a discussion around performance workloads for<br>
  OpenStack.  I plan to develop benchmarks to simulate such workloads and<br>
  it would be a good idea to list and prioritize some top number of<br>
  them.  Maybe this is too broad of a question, but it would be good to<br>
  have that feedback too.  Here is an an initial stab at it, listed in<br>
  priority order (highest first):<br>
</blockquote>
<br></div>
Are you planning to do this somehow "generic" so that other projects<br>
can write their own "workload test suite"?<br></blockquote><div><br></div><div>That is a good question.  I know I would get more help from the community if I were to contribute at least a part of what I develop back.  It will require approvals from Dell.  If I use an existing framework or load driver or project, it seems more likely that I would contribute back.  In short, I don't know, but would like to make it generic and extensible.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    Images with varying<br>
   1. number of images<br>
   2. sizes<br>
   3. formats<br>
   4. time to boot to log in and to finish booting<br>
</blockquote>
<br>
1) What about number of concurrent requests? If you're planning to boot<br>
many instances concurrently it might make sense to make sure Glance is<br>
capable of handling that load.<br></blockquote><div><br></div><div>I left testing of concurrency and scale off of the list.  It seems like those are applicable to all the workloads, but I do have a few thoughts:<br><ul><li>
Do ramp up testing to increase concurrency, e.g. over time increasing from one to n number of instances of the load generator<br></li><li>Do scale out testing, e.g. get maximum for one compute node, then two, then three, and so on</li>
</ul><p>As for Glance being able to handle the load, it would be interesting to determine if it is the bottleneck and identify ways to eliminate it as the bottleneck by scaling out or other tuning.  The same is true of any component.<br>
</p></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It would also be helpful to know what storage backend are you planning<br>
to use for this tests. I'd suggest using the local filesystem store.<br></blockquote><div><br></div><div>What backend storage to use might be part of the variations, but it does seem reasonable to start with local storage.<br>
<br></div><div>Ray<br></div></div></div></div>