Hi Robert Thanks for the comments.. Low-rate would be 100-200s of txn / sec High-rate would be 10K-20K txn / sec (to start with)
I agree, that there is third category (and probably the most challenging) - high throughput with lots of interaction. I also agree that there multiple ways to slice-and-dice the datastore usage. Slicing in this particular way however opens up the opportunities to leverage other opensource datastores. Regarding BGP, I had two queries... 1. Is the txn rate supported in a ODL-cluster enviroment? All our usecases require high availablility.. In particular the system needs to be resilent against SPOF. In order to fulfill these requirements, we have decided to use ODL clustering approach. 2. I am assuming the arrows (in peer -> AdjRIBIn -> EffRIBIn -> LocRib ) denote the interactions (via datastore notifications). If so, are these notifications used by some other ODL project / modules as well or are they used solely within BGP project? With regards Ashutosh -----Original Message----- From: Robert Varga [mailto:n...@hq.sk] Sent: Thursday, October 06, 2016 10:25 PM To: Ashutosh Bisht <ashutosh.bi...@ericsson.com>; mdsal-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org Subject: Re: [mdsal-dev] Use of external datastore in ODL Hello Ashutosh, On 10/06/2016 08:29 AM, Ashutosh Bisht wrote: > We have observed that there are two kind of datastore usage pattern in > ODL > > 1. Low-rate events that result in lot of interactions among ODL > modules. This could be for eg. a switch port-up event. > > 2. High-rate events with low interaction / almost pass-thru, that > just installs state in switch. This could be for eg. installing > subscriber filters for SFC classifier. It would be nice to attach some figures to low-rate and high-rate here. I do not believe this split is actually accurate nor should we start categorizing applications into such buckets. BGP is an example which is a combination of both, as it processes updates to the tune of 25K routes per second. It also performs processing via multiple stages (peer -> AdjRIBIn -> EffRIBIn -> LocRib, AdjRIBOut -> peer), which are connected via the data store. This architecture is key to realization of some of the more advanced use cases required by SPs, like custom route processing. Bye, Robert _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
