In the first for loop iteration, while trying to add 10 nhs each get call took 0.00043167 (averaged over 10 calls)
In the second for loop iteration, while trying to add 100 nhs each get call took 0.2018121 (averaged over 100 calls)
In the third for loop iteration, while trying to add 1000 nhs each get call took 0.40329421 (averaged over 49 calls)
All the 1000 nhs couldn’t be added because the test case timed out after one minute.
The benchmark get test case takes seems to be taking more time for every get call for successive for loop iterations (https://github.com/openconfig/gribigo/blob/main/compliance/get.go#L345)
In the first for loop iteration, while trying to add 10 nhs each get call took 0.00043167 (averaged over 10 calls) In the second for loop iteration, while trying to add 100 nhs each get call took 0.2018121 (averaged over 100 calls) In the third for loop iteration, while trying to add 1000 nhs each get call took 0.40329421 (averaged over 49 calls) All the 1000 nhs couldn’t be added because the test case timed out after one minute.
When I debugged this code I observed that we are losing on time waiting for the mutex: https://github.com/openconfig/gribigo/blob/main/client/gribiclient.go#L1041 the time spent waiting for the mutex lock keeps increasing after every for loop iteration as can be seen above.
The analysis was done sometime back. So, I do not know if this is still seen in the latest code base.