Latest sysrepo version having degraded performance about sysrepo HOT 3 OPEN

In short, everything works differently when comparing these 2 versions so I really am not able to tell you more. But if I understand your use-case correctly and you are sending 5000, 10000, ... edit-config requests for every measurement, that is a very inefficient way of working with data and we never really optimized that. Specifically, there is some overhead connected to every executed RPC, which is likely significantly higher in the current version but actual execution should not be slower. If you measure the use-cases some way, I could tell you more.

from sysrepo.

Hi,

Our test run is such that we are sending 1 entry per edit-config till the data tree has 60K entries, sequentially in one go. Once the test execution is completed, we then recorded the time taken by Nth request i.e 5000th, 1000th, 15000th.. and so on. We did the same steps for both old and the latest release and had the observation which we mentioned in our post.

Thanks and Regards.
Chinmaya Agarwal.

from sysrepo.

Okay, so I actually made the effort of trying to find out the exact reason for this difference. I tried a similar use-case to yours on both the current devel and the versions you have used before and got 57 ms vs 177 ms, which is similar to your numbers just faster in both cases.

But, then I tried to measure the performance of the old versions using callgrind and I failed. Ignoring the fact that I had to make some changes to even compile it and kept getting various internal and other errors, I ultimately realized that all the work is performed by sysrepod so I would have to measure that (but it kept crashing on some assert) so I gave up. However, when I looked at callgrind output of the current netopeer2, it included loading the previous JSON data because it was the first (and only) operation (that 5000th edit) that I executed so cache was not updated yet. When I then repeated the test with having the cache filled (I first sent an edit with 5000 instances, followed by another 1 instance), I got 55 ms. So, I could not reproduce the slower performance under normal circumstances. My only explanation for your measurements is you creating a new NETCONF session for each edit, then the cache would never be used, I believe. In the old version, sysrepod was caching the data so it would work.

TLDR; If you believe this performance difference to be accurate, please provide scripts and the complete steps to reproduce it.

from sysrepo.