# Perplexing benchmark result **URL:** \ **Category:** Elasticsearch\ **Created:** [October 16, 2012, 2:27am UTC](https://discuss.elastic.co/t/perplexing-benchmark-result/9366 "2012-10-16T02:27:16Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Yuhan](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@Yuhan](https://discuss.elastic.co/u/Yuhan)\ **Post date:** [October 16, 2012, 2:27am UTC](https://discuss.elastic.co/t/perplexing-benchmark-result/9366/1 "2012-10-16T02:27:16Z")
Hi all, I'm running some benchmark tests to try out the performance with settings with various number of shards. (I didnt take the indexing time into account). for now I'm just running elasticsearch locally on one machine (localhost), build index and ran apache bench against it The size of the index is about 100MB. The query is as simple as searching text against some fields: htttp://localhost:9200/media\_sources/\_search?\_routing=1001560&pretty=1&q=account\_id:1001560%20and%field1:_vampire_%20OR%20name:_vampire_%20 surprisingly, it appeared that the best case for me is to run with 1 shard. and more shards will only degrade the search time. Is this because my test is flawed as only running on one machine? another question about field routing. It appeared that with the same load setting from apache bench (1 node, 20 concurrent threads of 400 requests), elasticsearch tends to respond with a lot more failed requests (~175/400), while without routing the number of failed requests is only about ~12/400. I was expecting it to be more efficient as it only reads 1 shard at each request. looks like it made a lot works on 1 node. was \_routing designed to reduce the communications between nodes by limit to 1 shard at a time? what's the explanation in this case? Thank you. Yuhan -- ---
**Author:** ![simonw\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/simonw_2/32/1130_2.png) [@simonw\_2](https://discuss.elastic.co/u/simonw_2)\ **Post date:** [October 16, 2012, 8:00am UTC](https://discuss.elastic.co/t/perplexing-benchmark-result/9366/2 "2012-10-16T08:00:46Z")
Hey Yuhan, please find my comments inline... On Tuesday, October 16, 2012 4:27:19 AM UTC+2, Yuhan wrote: > Hi all, > > I'm running some benchmark tests to try out the performance with settings > with various number of shards. (I didnt take the indexing time into > account). > > for now I'm just running elasticsearch locally on one machine (localhost), > build index and ran apache bench against it > The size of the index is about 100MB. this is tiny and likely all you see is noise! Take some reasonable datasource \> 1M documents unless you won't see what you try to see 🙂 > The query is as simple as searching text against some fields: > > htttp://localhost:9200/media\_sources/\_search?\_routing=1001560&pretty=1&q=account\_id:1001560%20and%field1:_vampire_%20OR%20name:_vampire_%20 actually this query is not simple. it uses leading and trailing wildcards which is a very slow query so you might not measure what you are trying to measure. Most of the time will be spend in rewriting the query internally provided you hit any data but with you index size this is still super fast. > surprisingly, it appeared that the best case for me is to run with 1 > shard. and more shards will only degrade the search time. Is this because > my test is flawed as only running on one machine? this is not a surprise actually. you have one machine and multiple shards, that means you need to send requests to shards, have thread and maybe network overhead and need to merge results. while with one shard you don't have this overhead. You need to realize that sharding only makes sense if you have enough data. if not I'd just use replication and balance load across machines so you don't need to divide your request and merge. > another question about field routing. It appeared that with the same load > setting from apache bench (1 node, 20 concurrent threads of 400 requests), > elasticsearch tends to respond with a lot more failed requests (~175/400), > while without routing the number of failed requests is only about ~12/400. > I was expecting it to be more efficient as it only reads 1 shard at each > request. looks like it made a lot works on 1 node. was \_routing designed to > reduce the communications between nodes by limit to 1 shard at a time? > what's the explanation in this case? can you paste / gist the failures you see? simon > Thank you. > > Yuhan -- ---
**Author:** ![Yuhan](https://avatars.discourse-cdn.com/v4/letter/y/919ad9/32.png) [@Yuhan](https://discuss.elastic.co/u/Yuhan)\ **Post date:** [October 16, 2012, 6:18pm UTC](https://discuss.elastic.co/t/perplexing-benchmark-result/9366/3 "2012-10-16T18:18:30Z")
Hi Simon, Thanks for the analysis. looks like my data is small enough to go with 1 shard. 🙂 the test was conducted with apache bench. so I only got back a failure count and document size. will do more testing and find out the actual output. Thank you. Yuhan Document Path: /media\_sources/\_search?pretty=1&q=account\_id:1001560%20and%20long\_description:_vampire_%20OR%20name:_vampire_%20OR%20short\_description:_vampire_%20OR%20tags:_vampire_ Document Length: 6081 bytes Concurrency Level: 20 Time taken for tests: 19.700 seconds Complete requests: 400 Failed requests: 143 On Tue, Oct 16, 2012 at 1:00 AM, simonw [simon.willnauer@elasticsearch.com](mailto:simon.willnauer@elasticsearch.com)wrote: > Hey Yuhan, > > please find my comments inline... > > On Tuesday, October 16, 2012 4:27:19 AM UTC+2, Yuhan wrote: > > > Hi all, > > > > I'm running some benchmark tests to try out the performance with settings > > with various number of shards. (I didnt take the indexing time into > > account). > > > > for now I'm just running elasticsearch locally on one machine > > (localhost), build index and ran apache bench against it > > The size of the index is about 100MB. > > this is tiny and likely all you see is noise! Take some reasonable > datasource \> 1M documents unless you won't see what you try to see 🙂 > > > The query is as simple as searching text against some fields: > > htttp://localhost:9200/media\_ **sources/\_search?\_routing=** > > 1001560&pretty=1&q=account\_id: **1001560%20and%field1:_vampire_** > > %20OR%20name:_vampire_%20 > > actually this query is not simple. it uses leading and trailing wildcards > which is a very slow query so you might not measure what you are trying to > measure. Most of the time will be spend in rewriting the query internally > provided you hit any data but with you index size this is still super fast. > > > surprisingly, it appeared that the best case for me is to run with 1 > > shard. and more shards will only degrade the search time. Is this because > > my test is flawed as only running on one machine? > > this is not a surprise actually. you have one machine and multiple shards, > that means you need to send requests to shards, have thread and maybe > network overhead and need to merge results. while with one shard you don't > have this overhead. You need to realize that sharding only makes sense if > you have enough data. if not I'd just use replication and balance load > across machines so you don't need to divide your request and merge. > > > another question about field routing. It appeared that with the same load > > setting from apache bench (1 node, 20 concurrent threads of 400 requests), > > elasticsearch tends to respond with a lot more failed requests (~175/400), > > while without routing the number of failed requests is only about ~12/400. > > I was expecting it to be more efficient as it only reads 1 shard at each > > request. looks like it made a lot works on 1 node. was \_routing designed to > > reduce the communications between nodes by limit to 1 shard at a time? > > what's the explanation in this case? > > can you paste / gist the failures you see? > > simon > > > Thank you. > > > > Yuhan > > -- -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:08am UTC](https://discuss.elastic.co/t/perplexing-benchmark-result/9366/4 "2017-07-06T03:08:26Z")