Regarding transaction/request throughput, the bottleneck usually is the slowest device in the set of devices that are being touched as part of the NB request.
If we use a synchronous approach then the caller has to wait until all device programming is complete.
If we use an asynchronous approach then there is the option to queue/buffer, however if the queue doesn’t drain fast enough then the queue will continue to grow until we run out of system resources. Not sure if there is a limit to the queue size and this queue is more to handle big bursts of requests from the North. The bottleneck again will still usually be the slowest device in the change set. NSO has been optimised for performance to a great extent given that our entire configuration database (CDB) is in-memory.
There were some tests done with our L3VPN example and the throughput was 12-15 req/sec:
https://cisco.box.com/s/c86pydu6ibplk16d2hvv9yvlxg7t6f0y
However, the results may come out better if we are to use more powerful server for NSO. I remember a request being made to engineering to come up with updated document on server sizing and throughput measurements.
