Optimize ports stored in arrays in NoSQL

[Yuli]

Ports are not stored in optimized way in NoSQL structured.
As a result we have a speed degradation problem.
For example the reults of adding 1000 subnets to the same port:

time spend to create 100 subnets: 167
time spend to create 100 subnets: 173
time spend to create 100 subnets: 181
time spend to create 100 subnets: 189
time spend to create 100 subnets: 197
time spend to create 100 subnets: 207
time spend to create 100 subnets: 215
time spend to create 100 subnets: 219
time spend to create 100 subnets: 231
-----------------------------------------------------

If we look in add_lrouter_port() function, it does the following code:
1. Code fetches lrouter object from NoSQL
2. Performs Json decode
3. Add new port to the list of ports
4. Stringify back to json object
5. Stores new lrouter object back to NoSQL

When we have a lot of ports like I do have in stress test (i have hundreds of ports in router)
this becomes an issue. On each new port, the code has to cope with more data:
the json strings are bigger, more memory required to decode them;
we encode them back to string.

I suggest, we might need to store ports not in json array but as a NoSQL array,.
Currently we have /lrouter/<router-id> with a json data

We might add /lrouter/<router-id> and and /lrouter/<router-id>-ports

The new version of the add_lrouter_port() might be very simple.
Instead of reading lrouter and decoding, etc...
We will just push new port to /lrouter/<router-id>-ports

Here is an original bug:
https://bugs.launchpad.net/dragonflow/+bug/1556807

[Gal Sagie (gal-sagie)]

The same should also be applied to router and router ports

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/402092

[OpenStack Infra (hudson-openstack)]

Change abandoned by Shachar Snapiri (<email address hidden>) on branch: master
Review: https://review.openstack.org/402092

[Shachar Snapiri (snapiri)]

At the moment it seems like any change to the mechanism of adding ports will increase the time of port-addition in the common case of only a few ports for every router.
So it seems it is not cost-effective to fix the rare case of hundreds of ports per router on the cost of the more common one.
Anyway the scale we aim at is in number of routers per tenant and not in number of ports per router.