[Starlingx-discuss] [Testing][Performance metrics] Feedback required
Hello StarlingXers, We have been thinking in how to measure StarlingX performance, in order to do so, we would like to present you an initial proposal in order to get feedback and ideas from you guys. The proposed metrics for StarlingX performance are: * Detection of failed VM - tracked on milliseconds * Detection of failed compute node - tracked in milliseconds * Auto controller node failure recovery - No impact on StarlingX * Network link failure detection - tracked in milliseconds with no major impact on StarlingX We are considering the following tools for taking measurements and/or generating network traffic: * Iperf: IPerf3 is a tool for active measurements of the maximum achievable bandwidth on IP networks. o https://iperf.fr/ * Scapy: Simulating network traffic by creating packets and either saving a pcap file for further use or replaying the packets on a given interface o https://pypi.org/project/ScapyTrafficGenerator/ * Ostinato: Is a packet crafter, network traffic generator and analyzer with a friendly GUI. Also a powerful Python API for network test automation. o https://ostinato.org/ * T-rex: Is an open source, low cost, stateful and stateless traffic generator fueled by DPDK. It generates L4-7 traffic based on pre-processing and smart replay of real traffic templates o https://trex-tgn.cisco.com/ The proposed metrics cover functional areas that we believe are important for StarlinXers. Also, we know that Edge Computing Performance trending are focused on Latency and bandwidth, and we are going to land there (at some point). Regards -Ricardo
On 08/15/2018 03:37 PM, Perez, Ricardo O wrote:
Hello StarlingXers,
We have been thinking in how to measure StarlingX performance, in order to do so, we would like to present you an initial proposal in order to get feedback and ideas from you guys.
The proposed metrics for StarlingX performance are:
* Detection of failed VM – tracked on milliseconds
Are we talking the qemu process or intrusive guest monitoring? (Or both?)
* Detection of failed compute node – tracked in milliseconds
Different failure modes (power outage, mgmt link failure, critical process failure) could result in different detection times.
* Auto controller node failure recovery - No impact on StarlingX * Network link failure detection – tracked in milliseconds with no major impact on StarlingX
What about network failure beyond the first hop (so we don't lose carrier)? How about time from dead-office-recovery to instance network connectivity? Do we want to consider OpenStack performance? Chris
participants (2)
-
Chris Friesen
-
Perez, Ricardo O