# Impact of multiple concurrent scroll API on ElasticSearch

**URL:** <https://discuss.elastic.co/t/impact-of-multiple-concurrent-scroll-api-on-elasticsearch/206805>\
**Category:** Elasticsearch\
**Created:** [November 6, 2019, 2:09pm UTC](https://discuss.elastic.co/t/impact-of-multiple-concurrent-scroll-api-on-elasticsearch/206805 "2019-11-06T14:09:34Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [November 12, 2019, 11:55am UTC](https://discuss.elastic.co/t/impact-of-multiple-concurrent-scroll-api-on-elasticsearch/206805/2 "2019-11-12T11:55:58Z")

</div>

Scrolls are expensive to run concurrently.  
For each scroll ID there is a unique point-in-time view of the current set of segments preserved for that scroll. This hangs on to files and related caches that would otherwise be removed by the [constant segment rewriting](http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html) that happens while indexing is active. This is why it is especially resource-intensive to do concurrently.

---

_[View the full topic](https://discuss.elastic.co/t/impact-of-multiple-concurrent-scroll-api-on-elasticsearch/206805)._