Re: [Openstack] Performance metrics of RabbitMQServer
On 07/06/2012 06:52 AM, Naveen Kuna wrote: Hi All, Can anyone know performance metrics of RabbitMQServer ? Google is your friend :) http://stackoverflow.com/questions/7921324/performance-comparison-between-zeromq-rabbitmq-and-apache-qpid Keep in mind you have different feature sets between different message queue servers, so it's unlikely you will ever really get an apples to apples comparison. It's better for you to decide what features are critical to you *before* you just blindly go for one server that has better performance. The features you want to look over include things like persistence of messages (and options for persistence), HA setups, monitoring and management, etc. Is there any better alternative than RabbitMQServer ? See above. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Performance metrics of RabbitMQServer
Hi All, Can anyone know performance metrics of RabbitMQServer ? Is there any better alternative than RabbitMQServer ? Thanks in advance. Regards, Naveen Reddy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On 06/21/2012 02:21 PM, Rick Jones wrote: TSO and GRO can cover a multitude of path-length sins :) That is one of the reasons netperf does more than just bulk transfer :) When I was/am measuring scaling of an SMP node I would use aggregate, burst-mode, single-byte netperf TCP_RR tests to maximize the packets per second while minimizing the actual bandwidth consumed. And if there is a concern about flows coming and going there is the TCP_CRR test which is like the TCP_RR test but each transaction is a freshly created and torn-down TCP connection. It doesn't do TCP_CRR, and it is not geared towards the scores/hundreds/thousands of isntances, but I've just put a script into the netperf repository at netperf.org which will use novaclient.v1_1 to launch three instances of a specified flavor and run the runemomniaggdemo.sh script on one of them, targeting the other two. http://www.netperf.org/svn/netperf2/trunk/doc/examples/netperf_by_flavor.py Is it only my second bit of Python, so I'm sure it has lots of room for improvement, but perhaps it will be of use to folks and help act as a seed crystal. happy benchmarking, rick jones ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On 06/20/2012 08:09 PM, Huang Zhiteng wrote: On Thu, Jun 21, 2012 at 12:36 AM, Rick Jonesrick.jon...@hp.com wrote: I do not have numbers I can share, but do have an interest in discussing methodology for evaluating scaling particularly as regards to networking. My initial thoughts are simply starting with what I have done for network scaling on SMP systems (as vaguely instantiated in the likes of the runemomniaggdemo.sh script under http://www.netperf.org/svn/netperf2/trunk/doc/examples/ ) though expanding it by adding more and more VMs/hypervisors etc as one goes. By 'network scaling', do you mean the aggregated throughput (bandwidth, packets/sec) of the entire cloud (or part of it)? I think picking up 'netperf' as micro benchmark is just 1st step, there's more work needs to be done. Indeed. A great deal more. For OpenStack network, there's 'inter-cloud' and 'cloud-to-external-world' throughput. If we care about the performance for end user, then reason numbers (for network scaling) should be captured inside VM instances. For example, spawn 1,000 VM instances across cloud, then pair them to do 'netperf' tests in order to measure 'inter-cloud' network throughput. That would certainly be an interesting test yes. rick jones ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On Thu, Jun 21, 2012 at 11:16 AM, Rick Jones rick.jon...@hp.com wrote: On 06/20/2012 08:09 PM, Huang Zhiteng wrote: By 'network scaling', do you mean the aggregated throughput (bandwidth, packets/sec) of the entire cloud (or part of it)? I think picking up 'netperf' as micro benchmark is just 1st step, there's more work needs to be done. Indeed. A great deal more. For OpenStack network, there's 'inter-cloud' and 'cloud-to-external-world' throughput. If we care about the performance for end user, then reason numbers (for network scaling) should be captured inside VM instances. For example, spawn 1,000 VM instances across cloud, then pair them to do 'netperf' tests in order to measure 'inter-cloud' network throughput. That would certainly be an interesting test yes. We did a bunch of similar tests to determine the overhead caused by kvm and limitations of the nova network architecture. We found that VMs themselves were able to consistently saturate the network link available to the host system, whether it was 1GE or 10GE, with relatively modern node and network hardware. With the default VLANManager network setup, there isn't much you can do to scale your outbound connectivity beyond the hardware you can reasonably drive with a single node, but using multi-host nova-network, we were able to run a bunch of nodes in parallel, scaling up our outbound bandwidth linearly. We managed to get 10 nodes, with a single VM per node, each running 4 TCP streams, up to 99 gigabits on a dedicated cross country link. There was a bunch of tuning that we needed to do, but it wasn't anything particularly outlandish compared with the tuning needed for doing this with bare metal. We've been meaning to do a full writeup, but haven't had time yet. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On 06/21/2012 12:41 PM, Narayan Desai wrote: We did a bunch of similar tests to determine the overhead caused by kvm and limitations of the nova network architecture. We found that VMs themselves were able to consistently saturate the network link available to the host system, whether it was 1GE or 10GE, with relatively modern node and network hardware. With the default VLANManager network setup, there isn't much you can do to scale your outbound connectivity beyond the hardware you can reasonably drive with a single node, but using multi-host nova-network, we were able to run a bunch of nodes in parallel, scaling up our outbound bandwidth linearly. We managed to get 10 nodes, with a single VM per node, each running 4 TCP streams, up to 99 gigabits on a dedicated cross country link. There was a bunch of tuning that we needed to do, but it wasn't anything particularly outlandish compared with the tuning needed for doing this with bare metal. We've been meaning to do a full writeup, but haven't had time yet. TSO and GRO can cover a multitude of path-length sins :) That is one of the reasons netperf does more than just bulk transfer :) When I was/am measuring scaling of an SMP node I would use aggregate, burst-mode, single-byte netperf TCP_RR tests to maximize the packets per second while minimizing the actual bandwidth consumed. And if there is a concern about flows coming and going there is the TCP_CRR test which is like the TCP_RR test but each transaction is a freshly created and torn-down TCP connection. happy benchmarking, rick jones ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On Thu, Jun 21, 2012 at 4:21 PM, Rick Jones rick.jon...@hp.com wrote: TSO and GRO can cover a multitude of path-length sins :) Along with a 64 MB TCP window ;) That is one of the reasons netperf does more than just bulk transfer :) When I was/am measuring scaling of an SMP node I would use aggregate, burst-mode, single-byte netperf TCP_RR tests to maximize the packets per second while minimizing the actual bandwidth consumed. Yeah, for a completely random workload pps is the limiting factor. We're lucky in that our primary high bandwidth use case is wide area data transfer where we can fill our jumbo packets. (kudos to the nova folks on that count; we were completely able to configure jumbo frames without having to hack anything up) We were actually more thrilled to be able to build relatively fat single streams, due to our workload. -nld ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Performance metrics
Hi All, I want to do performance analysis on top of [openstack,Qauntum,openvswitch] setup. I am interested in the following metrics. VM life cycle (creation, deletion, boot..,etc) VM Migration Quantum (network, port creation/deletion..,etc) Are there any performance metric tools/scripts available in openstack ? If not, how can I do the performance analysis of the above metrics on openstack quantum setup ? Please help me regarding performance metrics. I want to know details of the biggest deployment with [openstack,Qauntum,openvswitch] setup interms of number of tenant networks, number of compute nodes, number of VMs per tenant. Thanks in advance. -- Thanks Regards Neelakantam Gaddam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On Wed, Jun 20, 2012 at 5:56 AM, Neelakantam Gaddam neelugad...@gmail.comwrote: Hi All, I want to do performance analysis on top of [openstack,Qauntum,openvswitch] setup. I am interested in the following metrics. VM life cycle (creation, deletion, boot..,etc) VM Migration Quantum (network, port creation/deletion..,etc) Are there any performance metric tools/scripts available in openstack ? If not, how can I do the performance analysis of the above metrics on openstack quantum setup ? Please help me regarding performance metrics. I want to know details of the biggest deployment with [openstack,Qauntum,openvswitch] setup interms of number of tenant networks, number of compute nodes, number of VMs per tenant. Most of the folks I know using Quantum are commercial companies, and I suspect they may consider information about their current cloud scale to be proprietary. However, perhaps someone else on the list would be able to volunteer some info on this. Dan Thanks in advance. -- Thanks Regards Neelakantam Gaddam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
Hi That's been my focus for a while now. We're using Tach to instrument openstack, quantum, glance and a bunch of other components. https://github.com/ohthree/tach Also, there's StackTach which will consume the notifications and give you a real-time display of what's happening in the system (as well as giving you a db of events you can query vs. parsing logfiles). https://github.com/rackspace/stacktach And, I recently submitted a patch to novaclient which adds a --timings option to see how long each API request takes. (and this review https://review.openstack.org/#/c/8672/ will add novaclient token caching for a slight speedup) Hope it helps! -Sandy From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Neelakantam Gaddam [neelugad...@gmail.com] Sent: Wednesday, June 20, 2012 9:56 AM To: openstack@lists.launchpad.net Subject: [Openstack] Performance metrics Hi All, I want to do performance analysis on top of [openstack,Qauntum,openvswitch] setup. I am interested in the following metrics. VM life cycle (creation, deletion, boot..,etc) VM Migration Quantum (network, port creation/deletion..,etc) Are there any performance metric tools/scripts available in openstack ? If not, how can I do the performance analysis of the above metrics on openstack quantum setup ? Please help me regarding performance metrics. I want to know details of the biggest deployment with [openstack,Qauntum,openvswitch] setup interms of number of tenant networks, number of compute nodes, number of VMs per tenant. Thanks in advance. -- Thanks Regards Neelakantam Gaddam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On 06/20/2012 05:56 AM, Neelakantam Gaddam wrote: Hi All, I want to do performance analysis on top of [openstack,Qauntum,openvswitch] setup. I am interested in the following metrics. VM life cycle (creation, deletion, boot..,etc) VM Migration Quantum (network, port creation/deletion..,etc) Are there any performance metric tools/scripts available in openstack ? If not, how can I do the performance analysis of the above metrics on openstack quantum setup ? Please help me regarding performance metrics. I want to know details of the biggest deployment with [openstack,Qauntum,openvswitch] setup interms of number of tenant networks, number of compute nodes, number of VMs per tenant. I do not have numbers I can share, but do have an interest in discussing methodology for evaluating scaling particularly as regards to networking. My initial thoughts are simply starting with what I have done for network scaling on SMP systems (as vaguely instantiated in the likes of the runemomniaggdemo.sh script under http://www.netperf.org/svn/netperf2/trunk/doc/examples/ ) though expanding it by adding more and more VMs/hypervisors etc as one goes. While netperf (or its like) is simply a microbenchmark, and so somewhat removed from reality it does have the benefit of not (directly at least :) leaking anything proprietary about what is going-on in any one vendor's environment. And if something will scale well under the rigors of netperf workloads it will probably scale well under real workloads. Such scaling under netperf may not be necessary, but it should be sufficient. happy benchmarking, rick jones ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On Thu, Jun 21, 2012 at 12:36 AM, Rick Jones rick.jon...@hp.com wrote: I do not have numbers I can share, but do have an interest in discussing methodology for evaluating scaling particularly as regards to networking. My initial thoughts are simply starting with what I have done for network scaling on SMP systems (as vaguely instantiated in the likes of the runemomniaggdemo.sh script under http://www.netperf.org/svn/netperf2/trunk/doc/examples/ ) though expanding it by adding more and more VMs/hypervisors etc as one goes. By 'network scaling', do you mean the aggregated throughput (bandwidth, packets/sec) of the entire cloud (or part of it)? I think picking up 'netperf' as micro benchmark is just 1st step, there's more work needs to be done. For OpenStack network, there's 'inter-cloud' and 'cloud-to-external-world' throughput. If we care about the performance for end user, then reason numbers (for network scaling) should be captured inside VM instances. For example, spawn 1,000 VM instances across cloud, then pair them to do 'netperf' tests in order to measure 'inter-cloud' network throughput. While netperf (or its like) is simply a microbenchmark, and so somewhat removed from reality it does have the benefit of not (directly at least :) leaking anything proprietary about what is going-on in any one vendor's environment. And if something will scale well under the rigors of netperf workloads it will probably scale well under real workloads. Such scaling under netperf may not be necessary, but it should be sufficient. happy benchmarking, rick jones -- Regards Huang Zhiteng ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
