# Batch reads performance **URL:** \ **Category:** Tuning\ **Created:** [November 26, 2019, 6:49pm UTC](https://discuss.aerospike.com/t/batch-reads-performance/6854 "2019-11-26T18:49:40Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Jean\_Wisser](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/jean_wisser/32/1321_2.png) [@Jean\_Wisser](https://discuss.aerospike.com/u/Jean_Wisser)\ **Post date:** [November 26, 2019, 6:49pm UTC](https://discuss.aerospike.com/t/batch-reads-performance/6854/1 "2019-11-26T18:49:40Z")
Hi, We are using aerospike for a batch read use case (no writes, no regular reads). We have found that latency is lower when using more but smaller nodes (we use gcloud). **CLUSTER A : 2 nodes** Node config : 16 vCPU 30 Go RAM 1x local SSD 375 Go 1x persistant SSD 400Go (configured as shadow device) **batch-index** ``` 10:18:55 10 19.70 1.97 0.00 6284.9 10:19:05 10 15.25 1.65 0.00 7013.9 10:19:15 10 16.00 1.51 0.00 5514.6 10:19:25 10 15.66 1.58 0.00 6931.0 -------------- ------ ------ ------ ---------- avg 16.44 1.36 0.01 7002.0 max 22.35 5.96 1.57 7286.6 ``` **CLUSTER B : 3 nodes** Node config : 8 vCPU 10 Go RAM 1x local SSD 375 Go 1x persistant SSD 400Go (configured as shadow device) **batch-index** ``` 10:36:41 10 3.37 0.08 0.00 7181.4 10:36:51 10 3.85 0.10 0.00 7156.7 10:37:01 10 3.52 0.08 0.00 7116.6 10:37:11 10 3.79 0.10 0.00 7218.2 -------------- ------ ------ ------ ---------- avg 7.00 0.16 0.00 6243.0 max 51.49 3.76 0.17 7397.2 ``` The load was exactly the same on the 2 clusters, we use batch index with 200 keys on a collection of 40M elements. The namespace is configured to be on SSD with index in memory. As you can see **on cluster A, 16% of read were \> 1ms whereas only 7% on cluster B**. None of the clusters were bounded by cpu during the test. **My questions are :** 1. Is the difference only related to the fact that we have 1 extra SSD on the 2nd cluster thus sharing the load between 3 disks instead of 2 disks ? Local SSD on gcloud have extremely high IOPS limits and we wouldn’t expect to notice a change 2. Is it possible that it is also related to the fact that 1 node handles less keys in memory thus retrieving a key is faster ? 3. Does the batch-index histogram also include client latency ? Sometimes we notice higher latencies and I am not sure if it comes from Aerospike or not. 4. As we only use the batch read operation, is it possible to fine tune aerospike to perform better even if it decreases the write/regular read latencies ? Thanks. ---
**Author:** ![meher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/meher/32/1644_2.png) [@meher](https://discuss.aerospike.com/u/meher)\ **Post date:** [November 28, 2019, 4:12am UTC](https://discuss.aerospike.com/t/batch-reads-performance/6854/2 "2019-11-28T04:12:29Z")
When requesting 200 keys across 2 nodes, each node will service ~100 keys. With 3 nodes, each node will service ~67 keys… That would make a difference for how much each node has to do. Enabling micro benchmarks for batch (refer to the [monitoring latency](https://www.aerospike.com/docs/operations/monitor/latency/index.html) documentation would provide more details on where the time is spent on the server (could be at demarshal for example, or when reading from storage). There are a variety of tuning that could be done to optimize, from having more partitions, increasing the post-write-queue, enabling read page cache, etc… The batch-index histogram only measures server side latency. Client side latency would have to be measured from the client.