Page Comparison

...

1. From 10 Parallel request (of 10 sequential request) the client can't always connect and we see time out error (succes ratio <100%)
   1. Sequential request are fired faster than actual responses so from DB perspective they are almost parallel request as well 
2. Database probably already become bottleneck with 2 threads, effectively firening a total of 20 call very quickly. Its know that the DB connection pool/internal will slow down from 12 or more 'parallel' request

Get 1000 nodes in Parallel with varying thread count

In this test, 1000 requests are sent using curl, but with varying thread count (using --parallel-max option).

echo -e "Threads\tTime"
for threads in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 20 30 40 50; do
	echo -n -e "$threads\t"
	/usr/bin/time -f "%e" curl --silent --output /dev/null --fail --show-error \
		--header "Authorization: Basic Y3BzdXNlcjpjcHNyMGNrcyE=" \
		--get "http://localhost:8883/cps/api/v1/dataspaces/openroadm/anchors/owb-msa221-anchor/node?xpath=/openroadm-devices/openroadm-device\[@device-id='C201-7-[1-25]A-[1-40]A1'\]&include-descendants=true" \
		--parallel --parallel-max $threads --parallel-immediate
done

Results

Observations

• Performance increases nearly linearly with increasing thread count, up to the number of CPU cores.
• Performance stops increasing when the number of threads equals the number of CPU cores (expected).
• Verbose statistics show that each individual request takes around 0.14 seconds, regardless of thread count (but with multiple CPU cores, requests are really done in parallel)

Data sheets