# Elasticsearch Query Performance while reading and writting in parallel **URL:** \ **Category:** Elasticsearch\ **Created:** [April 26, 2013, 8:06am UTC](https://discuss.elastic.co/t/elasticsearch-query-performance-while-reading-and-writting-in-parallel/11700 "2013-04-26T08:06:06Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ankit\_Jain](https://avatars.discourse-cdn.com/v4/letter/a/96bed5/32.png) [@Ankit\_Jain](https://discuss.elastic.co/u/Ankit_Jain)\ **Post date:** [April 26, 2013, 8:06am UTC](https://discuss.elastic.co/t/elasticsearch-query-performance-while-reading-and-writting-in-parallel/11700/1 "2013-04-26T08:06:06Z")
Hi All, We have setup 10 nodes ES cluster each has (16 cores and 32 GB RAM and 2 disk). We are using separate disk for each node. We have around 24 indices (10 shards each), size of index is 10 GB. Case1: We are able to fetch 10000 records in 9 secs if indexing is not running in parallel with query. Case2: When both indexing and query are running in parallel, then same query takes 70 secs. Thanks, Ankit Jain iLabs -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![radu\_gheorghe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radu_gheorghe/32/556_2.png) [@radu\_gheorghe](https://discuss.elastic.co/u/radu_gheorghe)\ **Post date:** [April 26, 2013, 1:01pm UTC](https://discuss.elastic.co/t/elasticsearch-query-performance-while-reading-and-writting-in-parallel/11700/2 "2013-04-26T13:01:15Z")
Hello Ankit, In case2, I assume you have slower query performance coming from 2 directions: - indexing creates additional load - indexing triggers merges, which invalidate caches If there's a lot of load generated by indexing, I don't see a good option to fix the issue, other than adding more/bigger nodes. Maybe increase the refresh\_interval. Also, 240 total shards sounds a little too much for 10 nodes. If your indexing is relatively light, you might counter the cache invalidation effect by using warmers[http://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/](http://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/) . ## Best regards, Radu [http://sematext.com/](http://sematext.com/) -- Elasticsearch -- Solr -- Lucene On Fri, Apr 26, 2013 at 11:06 AM, Ankit Jain [ankitjaincs06@gmail.com](mailto:ankitjaincs06@gmail.com)wrote: > Hi All, > > We have setup 10 nodes ES cluster each has (16 cores and 32 GB RAM and 2 > disk). We are using separate disk for each node. > > We have around 24 indices (10 shards each), size of index is 10 GB. > > Case1: > We are able to fetch 10000 records in 9 secs if indexing is not running in > parallel with query. > > Case2: > When both indexing and query are running in parallel, then same query > takes 70 secs. > > Thanks, > Ankit Jain > iLabs > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![radu\_gheorghe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radu_gheorghe/32/556_2.png) [@radu\_gheorghe](https://discuss.elastic.co/u/radu_gheorghe)\ **Post date:** [April 28, 2013, 8:44am UTC](https://discuss.elastic.co/t/elasticsearch-query-performance-while-reading-and-writting-in-parallel/11700/3 "2013-04-28T08:44:06Z")
Hello Ankit, For changing the refresh\_interval, I suggest you use the Indices Update Settings API: > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. Best regards, Radu On Fri, Apr 26, 2013 at 8:50 PM, Ankit Jain [ankitjaincs06@gmail.com](mailto:ankitjaincs06@gmail.com) wrote: > Hello Radu, > > Can you share the configuration details that i need to tweak to get the > near real time performance. > > Thanks & Regards, > Ankit Jain > iLabs > > On Friday, 26 April 2013 18:31:15 UTC+5:30, Radu Gheorghe wrote: > > > Hello Ankit, > > > > In case2, I assume you have slower query performance coming from 2 > > directions: > > > > - indexing creates additional load > > - indexing triggers merges, which invalidate caches > > > > If there's a lot of load generated by indexing, I don't see a good option > > to fix the issue, other than adding more/bigger nodes. Maybe increase the > > refresh\_interval. Also, 240 total shards sounds a little too much for 10 > > nodes. > > > > If your indexing is relatively light, you might counter the cache > > invalidation effect by using warmers[http://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/](http://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/) > > . > > > > ## Best regards, Radu > > > > [http://sematext.com/](http://sematext.com/) -- Elasticsearch -- Solr -- Lucene > > > > On Fri, Apr 26, 2013 at 11:06 AM, Ankit Jain [ankitj...@gmail.com](mailto:ankitj...@gmail.com) wrote: > > > > > Hi All, > > > > > > We have setup 10 nodes ES cluster each has (16 cores and 32 GB RAM and 2 > > > disk). We are using separate disk for each node. > > > > > > We have around 24 indices (10 shards each), size of index is 10 GB. > > > > > > Case1: > > > We are able to fetch 10000 records in 9 secs if indexing is not running > > > in parallel with query. > > > > > > Case2: > > > When both indexing and query are running in parallel, then same query > > > takes 70 secs. > > > > > > Thanks, > > > Ankit Jain > > > iLabs > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to elasticsearc...@\*\*[googlegroups.com](http://googlegroups.com). > > > > > > For more options, visit [https://groups.google.com/\*\*groups/opt\_out](https://groups.google.com/**groups/opt_out)[https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out) > > > . -- [http://sematext.com/](http://sematext.com/) -- Elasticsearch -- Solr -- Lucene -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**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, 2:39am UTC](https://discuss.elastic.co/t/elasticsearch-query-performance-while-reading-and-writting-in-parallel/11700/4 "2017-07-06T02:39:20Z")