# Transport.tcp.compress slowing down shard relocation

**URL:** <https://discuss.elastic.co/t/transport-tcp-compress-slowing-down-shard-relocation/148033>\
**Category:** Elasticsearch\
**Created:** [September 11, 2018, 1:49am UTC](https://discuss.elastic.co/t/transport-tcp-compress-slowing-down-shard-relocation/148033 "2018-09-11T01:49:08Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![ctluce](https://avatars.discourse-cdn.com/v4/letter/c/a9a28c/32.png) [@ctluce](https://discuss.elastic.co/u/ctluce)\
**Post date:** [September 21, 2018, 1:47am UTC](https://discuss.elastic.co/t/transport-tcp-compress-slowing-down-shard-relocation/148033/2 "2018-09-21T01:47:40Z")

</div>

What version of Elasticsearch are you using? This might be helpful if your running 6x [slow 6x shard recovery](https://discuss.elastic.co/t/elasticsearch-6-3-0-shard-recovery-is-slow/140940/7) Only way I was able to attain configured max\_bytes\_per\_sec was to disable compression, this was due to the change in concurrency between versions. If your running a different version then adjusting [settings](https://www.elastic.co/guide/en/elasticsearch/reference/2.4/recovery.html) may help you with shard recovery/relocation time with compression enabled, specifically `indices.recovery.concurrent_streams`

---

_[View the full topic](https://discuss.elastic.co/t/transport-tcp-compress-slowing-down-shard-relocation/148033)._