[openstack-dev] [FEMDC][MassivelyDistributed] Strawman proposal for message bus analysis
Ken Giusti
kgiusti at gmail.com
Fri Jun 23 20:46:10 UTC 2017
On Wed, Jun 21, 2017 at 10:13 AM, Ilya Shakhat <shakhat at gmail.com> wrote:
> Hi Ken,
>
> Please check scenarios and reports that exist in Performance Docs. In
> particular you may be interested in:
> * O.M.Simulator - https://github.com/openstack/o
> slo.messaging/blob/master/tools/simulator.py
> * MQ performance scenario - https://docs.openstack.org/dev
> eloper/performance-docs/test_plans/mq/plan.html#message-queue-performance
> * One of RabbitMQ reports - https://docs.openstack.org/dev
> eloper/performance-docs/test_results/mq/rabbitmq/cmsm/index.html
> * MQ HA scenario - https://docs.openstack.org/dev
> eloper/performance-docs/test_plans/mq_ha/plan.html
> * One of RabbitMQ HA reports - https://docs.openstack.org/dev
> eloper/performance-docs/test_results/mq_ha/rabbitmq-ha-
> queues/cs1ss2-ks2-ha/omsimulator-ha-call-cs1ss2-ks2-ha/index.html
>
>
Thank you Ilya - these tests you reference are indeed valuable.
But, IIUC, those tests benchmark queue throughput, using a single (highly
threaded) client->single server traffic flow. If that is the case, I
think the tests we're trying to define might be a bit more specific to the
FEMDC [0] use cases: multiple servers consuming from different topics
while many clients distributed across the message bus are connecting,
generating traffic, failing over, etc.
The goal of these tests would be to quantify the behavior of the message
bus as a whole under different messaging loads, failure conditions, etc.
[0] https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds
>
> Thanks,
> Ilya
>
> 2017-06-21 15:23 GMT+02:00 Ken Giusti <kgiusti at gmail.com>:
>
>> Hi All,
>>
>> Andy and I have taken a stab at defining some test scenarios for anal the
>> different message bus technologies:
>>
>> https://etherpad.openstack.org/p/1BGhFHDIoi
>>
>> We've started with tests for just the oslo.messaging layer to analyze
>> throughput and latency as the number of message bus clients - and the bus
>> itself - scale out.
>>
>> The next step will be to define messaging oriented test scenarios for an
>> openstack deployment. We've started by enumerating a few of the tools,
>> topologies, and fault conditions that need to be covered.
>>
>> Let's use this epad as a starting point for analyzing messaging - please
>> feel free to contribute, question, and criticize :)
>>
>> thanks,
>>
>>
>>
>> --
>> Ken Giusti (kgiusti at gmail.com)
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Ken Giusti (kgiusti at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170623/702ed681/attachment.html>
More information about the OpenStack-dev
mailing list