Honeycomb performance test proposal
Samuel Elias -X (samelias - PANTHEON TECHNOLOGIES@Cisco)
My Initial proposal for Honeycomb performance testing is as follows.
- single Jenkins job, manually triggered. Change to weekly once it's showing good numbers.
- use VPP and Honeycomb packages from Nexus, and ODL client(Boron-SR3).
Note: ODL may have to be stored locally due to the download size(around 400MB) - on the test nodes? on Nexus?
- setup VPP+Honeycomb+ODL stack on DUT1
- setup TRex on TG
- use TRex to generate Restconf requests
- send requests to ODL, performing CRUD operations on VPP config
- catch and measure responses on TG
Note: Management requests cannot be sent over the data plane(VPP interfaces), as they need to be received by ODL's listener. Assuming the management interfaces(10.30.51._ range) should not be used for tests, we will have to give control of VPP's "tg_to_dut1"
test interface back to the linux OS for the duration of test.
(initially using L2-FIB yang model, it's simple and scaleable)
Given X amount of configured FIB entries
- TC01: avg. delay of read operation
- TC02: avg. delay of write operation
- TC03: max rate of read operations
- TC04: max rate of write operations
using NDR binary search to determine max rate.
Expected execution time for the initial cases (incl. suite setup and teardown): <60min
Thoughts and opinions are welcome.