Hi Luis, thanks for writing this up, some suggestions/comments on test 1) only so far below, Al
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Luis Gomez > Sent: Wednesday, July 27, 2016 6:13 PM > To: [email protected]; openflowplugin-dev; Jin Gan; > Sanjib Mohapatra > Subject: [integration-dev] OpenFlow tests for next ODL perf paper > > 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. [ACM] I think it's good to delineate each of these time intervals, especially if we are looking for the long wait or see unexpected waiting. IMO, the overall time to conduct the REST programming operation is useful, as this is what will be relevant in a production environment. (My minimal knowledge of the NB interface is about to show, mea culpa) It seems to me that 100K is a large number, and that if the controller started the operation when the first flow requests arrive on NB, the overall programming time (relevant in production) would be reduced. If each bulk request must be completely received before any SB action, then the way to reduce overall programming time would be to divide the 100K flows into smaller chunks and the controller can start work when one arrives. This would cause some of the time intervals to overlap, and possibly change in length from the 100K case. But if dividing 100K into chunks is more realistic from a production network perspective, we should consider it here. _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
