Aerospike_batch_get - slow response if called from 10 parallel threads vs 400

1

I am using aerospike_batch_get for benchmarking

If I call aerospike_batch_get for 4 keys ( 1k of record size per key) over 400 parallel threads, 30 qps per thread on a three node cluster, the response time is good (1 ms avg).

But if I do the same over just 10 parallel threads, the response time increases drastically (2 ms avg).

But now I put the load as 600 qps per thread, the response time is good (1 ms avg)

This is with as_policy_batch.concurrent = 0

Any idea if the connection has to be reestablished each time if not used for certain duration?

I am blocked on this non linear results.

thanks! -Vikrant

2

It depends on the client and server configurations for idle policies. We recommend, for typical use cases, to set both to 0, meaning connections would remain open for as long as client/node are up and running (proto-fd-idle-ms 0 and, let’s say for the Java client: maxSocketIdle of 0). You can also specify a minimum number of connections to be established to make sure there is no slow down while establishing the connections as part of a traffic ramp up.