[openstack-dev] Interesting and representative performance workloads for OpenStack

Ray Pekowski pekowski at gmail.com
Wed Apr 24 17:50:45 UTC 2013

Flavio, thanks for the input

On Wed, Apr 24, 2013 at 6:44 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 23/04/13 17:37 -0500, Ray Pekowski wrote:
>>   I would like to start a discussion around performance workloads for
>>   OpenStack.  I plan to develop benchmarks to simulate such workloads and
>>   it would be a good idea to list and prioritize some top number of
>>   them.  Maybe this is too broad of a question, but it would be good to
>>   have that feedback too.  Here is an an initial stab at it, listed in
>>   priority order (highest first):
> Are you planning to do this somehow "generic" so that other projects
> can write their own "workload test suite"?

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.

>      Images with varying
>>    1. number of images
>>    2. sizes
>>    3. formats
>>    4. time to boot to log in and to finish booting
> 1) What about number of concurrent requests? If you're planning to boot
> many instances concurrently it might make sense to make sure Glance is
> capable of handling that load.

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:

   - Do ramp up testing to increase concurrency, e.g. over time increasing
   from one to n number of instances of the load generator
   - Do scale out testing, e.g. get maximum for one compute node, then two,
   then three, and so on

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

> It would also be helpful to know what storage backend are you planning
> to use for this tests. I'd suggest using the local filesystem store.

What backend storage to use might be part of the variations, but it does
seem reasonable to start with local storage.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130424/76af1b69/attachment-0001.html>

More information about the OpenStack-dev mailing list