# ES Benchmark using rally to stress a 2 node setup

**URL:** <https://discuss.elastic.co/t/es-benchmark-using-rally-to-stress-a-2-node-setup/150020>\
**Category:** Elasticsearch\
**Tags:** rally\
**Created:** [September 26, 2018, 1:26pm UTC](https://discuss.elastic.co/t/es-benchmark-using-rally-to-stress-a-2-node-setup/150020 "2018-09-26T13:26:43Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\
**Post date:** [October 11, 2018, 9:41am UTC](https://discuss.elastic.co/t/es-benchmark-using-rally-to-stress-a-2-node-setup/150020/6 "2018-10-11T09:41:00Z")

</div>

Hi,

> [@Jorge\_Betancourt](#):
>
> Exactly, but in this case if it's reading from the page cache then putting rally on an SSD machine will not provide an additional benefit right?

Yes, that's correct. If the data set is completely cached then you shouldn't see a difference. I just wanted to point out that a spinning disk might be problematic if you use multiple clients.

Based on what you describe I still wonder whether lock contention is causing your bottleneck. I still think that the best option to spot this, is to attach a profiler to Elasticsearch while you are running the benchmark. Then this becomes pretty evident when you look at the thread states of the bulk indexing threads.

Daniel

---

_[View the full topic](https://discuss.elastic.co/t/es-benchmark-using-rally-to-stress-a-2-node-setup/150020)._