Hi,
See the ConfD UG section “The Protocol and a Library Threads Discussion”, last paragraph:
When we use multiple threads, it is important to remember that threads can not “share” socket connections to ConfD. For the data provider API, this is basically fulfilled automatically, as we will not have multiple threads polling the same socket. But when we use e.g. the CDB or MAAPI APIs, the application must make sure that each thread has its own sockets. I.e. the ConfD API functions are thread-safe as such, but multiple threads using them with the same socket will have unpredictable results, just as multiple threads using the read() and write() system calls on the same file descriptor in general will. In the ConfD case, one thread may end up getting the response to a request from another, or even a part of that response, which will result in errors that can be very difficult to debug.
Example issue as a reference:
ConfD consumes no CPU and very little memory until your application add YANG models, data, and start using the APIs. Hence, the CPU and memory consumption depends on the application and how it integrates with ConfD.
See, for example, this demo application run.sh script for an example on how a simple shell script can be used to run test cases and measure wall-clock time for different northbound agent read requests, including ConfD’s memory usage (RSS) at the end of the test case and highwater mark memory usage (HWM), i.e., peak memory usage for the test case.