> On Jul 27, 2016, at 3:19 PM, Anil Vishnoi <[email protected]> wrote: > > > > On Wed, Jul 27, 2016 at 3:13 PM, Luis Gomez <[email protected] > <mailto:[email protected]>> wrote: > Hi all, > > I got the action point from last S3P call to start some discussion around > OpenFlow tests we can do for next ODL perf paper (Boron). > > I am not sure we will have time for all the below but ideally I was thinking > in 4 tests: > > 1) REST programming performance: > > - Goal: Measure OF programming rate using NB REST interface > - Methodology: Use test REST scripts (flows in datastore) to program 100K > flows on an OF network of different size: 16-32-64-128 switches, etc... > - Test variations: Use single flow/REST request and multiple flows/REST > (bulk) request. > - Collected data: controller programming time (from first to last flow) from > REST script, switch programming time (from first to last flow) polling the > OVS, flow confirmation delay (time after T1) polling the operational DS. > I am not sure this test will give correct openflowplugin performance, > because in my understanding NB rest interface is bottleneck here. This test > probably we can use to show the restconf interface performance test.
Yes that is the idea, REST performance, but also bulk requests put high load on the plugin. > > > 2) Java programming performance: > > - Goal: Measure OF programming rate using internal Java interface > - Methodology: Use bluk-o-matic application (flows in datastore or rpc) to > program 100K flows on an OF network of different size: 16-32-64-128 switches, > etc... > - Test variations: Use single flow/REST request and multiple flows/REST > (bulk) request. > - Collected data: controller programming time (from first to last flow) from > bulk-o-matic, switch programming time (from first to last flow) polling the > OVS, flow confirmation delay (time after T1) polling the operational DS. > > 3) Network message processing latency: > > - Goal: Measure OF packet message processing time > - Methodology: Use some OF public tool (Cbench, MT-Cbench, SDN-blaster) to > generate OF packets and measure the delay (latency mode) of the received > controller flows on an OF network of different size: 16-32-64-128 switches, > etc... > - Test variations: Use controller drop-test application in DS and RPC mode. > - Collected data: packet processing rate (latency=1/rate) > > 4) Topology scalability: > > - Goal: Scale OF network and measure learning time. > - Methodology: Use some OF public tool (Mininet, Multinet) to generate > different sizes of large topologies: 1000, 2000, 3000 switches, etc... > - Collected data: Time for the controller to learn about the topology. > > In addition the same tests (or a subset) should run in a cluster environment > (3 node cluster). > > The main problem we have today for running and automating the above is people > resources, so far Jin and Sanjib offered to help but more help would be > appreciated. > > BR/Luis > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > <mailto:[email protected]> > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev> > > > > -- > Thanks > Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
