[openstack-dev] Announce of Rally - benchmarking system for OpenStack

Boris Pavlovic boris at pavlovic.me
Sat Dec 28 20:02:15 UTC 2013


Ali Gamal,

?



Tim,

Yes it fits.

There are couple of use cases that should be covered by Rally:

1) Easy way to find & fix bottlenecks/scale issues & improve performance of
OS (without having tons of servers)
2) Find the best Arch for your hardware and your typical loads
3) Ensure that existing installation pass SLA
4) Ensure that OpenStack VMs have their resources and work as expected
(already started discussion)



Best regards,
Boris Pavlovic




On Sat, Dec 28, 2013 at 11:40 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

>
>
> I think there also needs to be a scalability best practise and reference
> architecture.
>
>
>
> Benchmarking allows us to identify problems with the code but we also need
> some community wisdom on how to deploy at scale.
>
>
>
> Does this fit within Rally or can you advise where this community wisdom
> should be accumulated ?
>
>
>
> Tim
>
>
>
>
>
> *From:* Ali Gamal [mailto:agamal at itsyn.com]
> *Sent:* 28 December 2013 20:31
>
> *To:* OpenStack Development Mailing List
> *Cc:* Ali Beddah
> *Subject:* Re: [openstack-dev] Announce of Rally - benchmarking system
> for OpenStack
>
>
>
> On Oct 17, 2013 12:45 AM, "Boris Pavlovic" <bpavlovic at mirantis.com> wrote:
>
>  Hi Stackers,
>
>
> We are thrilled to present to you Rally, the benchmarking system for
> OpenStack.
>
>
> It is not a secret that we have performance & scaling issues and that
> OpenStack won’t scale out of box. It is also well known that if you get
> your super big DC (5k-15k servers) you are able to find & fix all OpenStack
> issues in few months (like Rackspace, BlueHost & others have proved). So
> the problem with performance at scale is solvable.
>
>
> The main blocker to fix such issues in community is that there is no
> simple way to get relevant and repeatable “numbers” that represent
> OpenStack performance at scale. It is not enough to tune an individual
> OpenStack component, because its performance at scale is no guarantee that
> it will not introduce a bottleneck somewhere else.
>
>
> The correct approach to comprehensively test OpenStack scalability, in our
> opinion, consists of the following four steps:
>
> 1)  Deploy OpenStack
> 2)  Create load by simultaneously making OpenStack API calls
> 3)  Collect performance and profile data
> 4)  Make data easy to consume by presenting it in a humanly readable form
>
>
> Rally is the system that implements all the steps above plus it maintains
> an extendable repository of standard performance tests. To use Rally, a
> user has to specify where to deploy OS, select the deployment mechanism
> (DevStack, Triple-O, Fuel, Etc.) and the set of benchmarking tests to run.
>
> For more details and how to use it take a look at our wiki
> https://wiki.openstack.org/wiki/Rally it should already work out of box.
>
>
> Happy hunting!
>
>
> Links:
>
> 1. Code: https://github.com/stackforge/rally
>
>
>
> 2. Wiki: https://wiki.openstack.org/wiki/Rally
>
> 2. Launchpad: https://launchpad.net/rally
>
> 3. Statistics:
> http://stackalytics.com/?release=havana&project_type=All&module=rally
>
> 4. RoadMap: https://wiki.openstack.org/wiki/Rally/RoadMap
>
>
> Best regards,
> Boris Pavlovic
> ---
> Mirantis Inc.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131229/992a2bcc/attachment.html>


More information about the OpenStack-dev mailing list