# Bulk update is too slow elasticsearch 6.2

**URL:** <https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213>\
**Category:** Elasticsearch\
**Created:** [April 24, 2018, 5:01am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213 "2018-04-24T05:01:50Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [May 7, 2018, 8:15am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213/21 "2018-05-07T08:15:35Z")

</div>

> You can go for split brain architecture where 2 master will be there. You can divide your heavy update load into two master.

This does not make any sense to me as master nodes are not involved in the request flow. If you were to index into a cluster suffering from split-brain you would also end up losing data.

---

<div class="post-metadata">

**Author:** ![ashishtiwari1993](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ashishtiwari1993/32/135241_2.png) [@ashishtiwari1993](https://discuss.elastic.co/u/ashishtiwari1993)\
**Post date:** [May 7, 2018, 9:14am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213/22 "2018-05-07T09:14:03Z")

</div>

@Christian_Dahlqvist thanks for correction. I ll edit my gist. But one doubt if i have two master node and i am having 500 write request at a time, so can i divide 250 request to one master and another 250 to other master. Would it be good ?

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [May 7, 2018, 9:49am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213/23 "2018-05-07T09:49:06Z")

</div>

What matters is the number of data nodes, not whether they are master-eligible or not. The work is done at the shard level, so if you have enough cores available to process them all in parallel, I am not sure adding a second node on t he same hardware will help much.

---

<div class="post-metadata">

**Author:** ![ashishtiwari1993](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ashishtiwari1993/32/135241_2.png) [@ashishtiwari1993](https://discuss.elastic.co/u/ashishtiwari1993)\
**Post date:** [May 7, 2018, 10:57am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213/24 "2018-05-07T10:57:30Z")

</div>

So if i add multiple data node should my write performance increase ?

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [May 7, 2018, 11:24am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213/25 "2018-05-07T11:24:16Z")

</div>

If performance is limited by resources, scaling out to more nodes can greatly increase write performance as more hardware resources can be used. In your case you are however not saturating resources, so I am therefore not sure how much scaling out would actually help.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [June 4, 2018, 11:24am UTC](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213/26 "2018-06-04T11:24:20Z")

</div>

Closed on June 4, 2018, 11:24am UTC

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

[Previous page](https://discuss.elastic.co/t/bulk-update-is-too-slow-elasticsearch-6-2/129213.md?page=1)
