# Poor Update Performance Despite Refresh Interval Compromise **URL:** \ **Category:** Elasticsearch\ **Created:** [April 23, 2014, 2:01pm UTC](https://discuss.elastic.co/t/poor-update-performance-despite-refresh-interval-compromise/17150 "2014-04-23T14:01:26Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Nariman\_Haghighi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nariman_haghighi/32/1065_2.png) [@Nariman\_Haghighi](https://discuss.elastic.co/u/Nariman_Haghighi)\ **Post date:** [April 23, 2014, 2:01pm UTC](https://discuss.elastic.co/t/poor-update-performance-despite-refresh-interval-compromise/17150/1 "2014-04-23T14:01:26Z")
Running a 2-node cluster, we're experiencing less than ideal update times even after adjusting the refresh interval. Settings are: "number\_of\_replicas":"1","number\_of\_shards":"5","refresh\_interval":"5s" The two VMs are 4 cores, 7 GB of ram, and the following are response times reported (on avg - over a 2-3 month duration): Imported 2475 documents in 7107 milliseconds Imported 2475 documents in 4862 milliseconds Imported 2475 documents in 6015 milliseconds Imported 2475 documents in 5991 milliseconds My understanding of the reported times (using [Elasticsearch.NET](http://Elasticsearch.NET)'s IBulkRequest Took) is that they don't involve the network delays associated with getting the request to ES, just the server processing time: [https://github.com/elasticsearch/elasticsearch-net/issues/453](https://github.com/elasticsearch/elasticsearch-net/issues/453) Are these times considered below/average/above given your experience? Can anything else be done to improve indexing performance here? -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/44863f41-1eac-4294-a710-c00d7ea8e1bc%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/44863f41-1eac-4294-a710-c00d7ea8e1bc%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [April 23, 2014, 2:13pm UTC](https://discuss.elastic.co/t/poor-update-performance-despite-refresh-interval-compromise/17150/2 "2014-04-23T14:13:48Z")
On Wed, Apr 23, 2014 at 10:01 AM, Nariman Haghighi [auspicious@gmail.com](mailto:auspicious@gmail.com)wrote: Running a 2-node cluster, we're experiencing less than ideal update times > even after adjusting the refresh interval. > > Settings are: > "number\_of\_replicas":"1","number\_of\_shards":"5","refresh\_interval":"5s" > > The two VMs are 4 cores, 7 GB of ram, and the following are response times > reported (on avg - over a 2-3 month duration): > > Imported 2475 documents in 7107 milliseconds > Imported 2475 documents in 4862 milliseconds > Imported 2475 documents in 6015 milliseconds > Imported 2475 documents in 5991 milliseconds > > My understanding of the reported times (using [Elasticsearch.NET](http://Elasticsearch.NET)'s > IBulkRequest Took) is that they don't involve the network delays associated > with getting the request to ES, just the server processing time: > [Support for GZIP on PUT/POST · Issue #453 · elastic/elasticsearch-net · GitHub](https://github.com/elasticsearch/elasticsearch-net/issues/453) > > Are these times considered below/average/above given your experience? Can > anything else be done to improve indexing performance here? It really depends on the size of the documents and how cpu heavy the analysis is. I feel pretty good when I can get 5,000 per second across 16 severs with 96GB of ram and 12 (couple year old) cpus. But my documents are generally a couple hundred KB and range up into tens of MB. OTOH, I can't overwhelm the servers because they are still performing searching during this time so I try to keep the bump in cpu load due to this kind of bulk indexing around 25%. The standard advice is to shut off the refresh interval during bulk loads if you can get away with it and make sure you are doing them across many threads. Nik -- 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). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAPmjWd3ya0zWwSaFk5%2B4Az4BuUqYyqVht-0RhaQn303z23Or%2BQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPmjWd3ya0zWwSaFk5%2B4Az4BuUqYyqVht-0RhaQn303z23Or%2BQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 1:34am UTC](https://discuss.elastic.co/t/poor-update-performance-despite-refresh-interval-compromise/17150/3 "2017-07-06T01:34:04Z")