# Performance tuning for alias creation **URL:** \ **Category:** Elasticsearch\ **Created:** [March 28, 2013, 6:43pm UTC](https://discuss.elastic.co/t/performance-tuning-for-alias-creation/11364 "2013-03-28T18:43:13Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![paul\_mclellan](https://avatars.discourse-cdn.com/v4/letter/p/b487fb/32.png) [@paul\_mclellan](https://discuss.elastic.co/u/paul_mclellan)\ **Post date:** [March 28, 2013, 6:43pm UTC](https://discuss.elastic.co/t/performance-tuning-for-alias-creation/11364/1 "2013-03-28T18:43:13Z")
Hi, we've recently started using Elasticsearch within our application and are experiencing slow response times when creating aliases. We've adopted the 'users data flow' model described in this presentation - [http://www.elasticsearch.org/videos/big-data-search-and-analytics/](http://www.elasticsearch.org/videos/big-data-search-and-analytics/) - and are generating filtered aliases for each user in the system. As part of our automated test process we are creating a number of new users in a short space of time. This, in turn, triggers the generation of new indices within Elasticsearch and this is where we are experiencing unexpected delays. For example, during a recent test run we created 44 new aliases within a 70 second period. The time taken for these operations to complete began at around 2 seconds but had dropped off to 69 seconds by the end. This represents a particularly extreme case, but response times of over 20 seconds are quite common. Generally the pattern is the same. Response times will be good to start with and then gradually degrade as more requests are sent. In terms of our set-up, we have a single Elasticsearch node shared between multiple (~8) environments. Each environment has a separate index with 5 shards allocated to it. Our largest shards are storing around 2 million documents, all of which are reasonably small. My questions are: - Is this kind of behaviour expected when attempting to create multiple aliases in a relatively short space of time? - Are there any settings that we can experiment with to improve performance? - Is this likely to be a side effect of our current architecture (i.e. sharing a single node between several environments)? - What are the most useful stats that we can monitor on the server to help diagnose the cause of the delays? Any insight you can offer will be greatly appreciated. Thanks, Paul -- 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:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [April 2, 2013, 7:18am UTC](https://discuss.elastic.co/t/performance-tuning-for-alias-creation/11364/2 "2013-04-02T07:18:10Z")
Hey Paul, this looks really strange. There is a recent change about aliases processing in the master branch. Is it possible for you to test this? For more info see > > > A large number of aliases may result in noticeable delays during index recovery. > > > Closes# 2832 On Thu, Mar 28, 2013 at 7:43 PM, [paul.mclellan@globalrelay.com](mailto:paul.mclellan@globalrelay.com) wrote: > Hi, > > we've recently started using Elasticsearch within our application and are > experiencing slow response times when creating aliases. We've adopted the > 'users data flow' model described in this presentation - > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/videos/big-data-search-and-analytics/) - and > are generating filtered aliases for each user in the system. > > As part of our automated test process we are creating a number of new > users in a short space of time. This, in turn, triggers the generation of > new indices within Elasticsearch and this is where we are experiencing > unexpected delays. For example, during a recent test run we created 44 new > aliases within a 70 second period. The time taken for these operations to > complete began at around 2 seconds but had dropped off to 69 seconds by the > end. This represents a particularly extreme case, but response times of > over 20 seconds are quite common. Generally the pattern is the same. > Response times will be good to start with and then gradually degrade as > more requests are sent. > > In terms of our set-up, we have a single Elasticsearch node shared between > multiple (~8) environments. Each environment has a separate index with 5 > shards allocated to it. Our largest shards are storing around 2 million > documents, all of which are reasonably small. > > My questions are: > > - Is this kind of behaviour expected when attempting to create > multiple aliases in a relatively short space of time? > - Are there any settings that we can experiment with to improve > performance? > - Is this likely to be a side effect of our current architecture (i.e. > sharing a single node between several environments)? > - What are the most useful stats that we can monitor on the server to > help diagnose the cause of the delays? > > Any insight you can offer will be greatly appreciated. > > Thanks, > Paul > > -- > 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:** ![paul\_mclellan](https://avatars.discourse-cdn.com/v4/letter/p/b487fb/32.png) [@paul\_mclellan](https://discuss.elastic.co/u/paul_mclellan)\ **Post date:** [April 2, 2013, 4:59pm UTC](https://discuss.elastic.co/t/performance-tuning-for-alias-creation/11364/3 "2013-04-02T16:59:29Z")
Thanks Alexander. Should be possible to test the latest code on our server. I'll give it a whirl and see if things improve. Cheers, Paul On Tuesday, 2 April 2013 00:18:10 UTC-7, Alexander Reelsen wrote: > Hey Paul, > > this looks really strange. There is a recent change about aliases > processing in the master branch. Is it possible for you to test this? > For more info see > > [Optimize aliases processing · Issue #2832 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/2832) > > [Optimize aliases processing · elastic/elasticsearch@b657bdf · GitHub](https://github.com/elasticsearch/elasticsearch/commit/b657bdfa1a9467848cc1844b5c732087e5eae1ca) > > On Thu, Mar 28, 2013 at 7:43 PM, \<[paul.m...@globalrelay.com](mailto:paul.m...@globalrelay.com) \\>wrote: > > > Hi, > > > > we've recently started using Elasticsearch within our application and are > > experiencing slow response times when creating aliases. We've adopted the > > 'users data flow' model described in this presentation - > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/videos/big-data-search-and-analytics/) - and > > are generating filtered aliases for each user in the system. > > > > As part of our automated test process we are creating a number of new > > users in a short space of time. This, in turn, triggers the generation of > > new indices within Elasticsearch and this is where we are experiencing > > unexpected delays. For example, during a recent test run we created 44 new > > aliases within a 70 second period. The time taken for these operations to > > complete began at around 2 seconds but had dropped off to 69 seconds by the > > end. This represents a particularly extreme case, but response times of > > over 20 seconds are quite common. Generally the pattern is the same. > > Response times will be good to start with and then gradually degrade as > > more requests are sent. > > > > In terms of our set-up, we have a single Elasticsearch node shared > > between multiple (~8) environments. Each environment has a separate index > > with 5 shards allocated to it. Our largest shards are storing around 2 > > million documents, all of which are reasonably small. > > > > My questions are: > > > > - Is this kind of behaviour expected when attempting to create > > multiple aliases in a relatively short space of time? > > - Are there any settings that we can experiment with to improve > > performance? > > - Is this likely to be a side effect of our current architecture > > (i.e. sharing a single node between several environments)? > > - What are the most useful stats that we can monitor on the server to > > help diagnose the cause of the delays? > > > > Any insight you can offer will be greatly appreciated. > > > > Thanks, > > Paul > > > > -- > > 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](mailto:elasticsearc...@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:** ![paulmclellan\_00](https://avatars.discourse-cdn.com/v4/letter/p/58f4c7/32.png) [@paulmclellan\_00](https://discuss.elastic.co/u/paulmclellan_00)\ **Post date:** [April 11, 2013, 9:29pm UTC](https://discuss.elastic.co/t/performance-tuning-for-alias-creation/11364/4 "2013-04-11T21:29:17Z")
Hi, haven't had a chance to test the latest code yet, got distracted by other work. However, I wanted to post an update concerning another possible bottleneck for alias creation. The InternalClusterService is using an executor service with a single thread to process all the alias updates it receives. This, in turn, hits the IndicesClusterStateService where the new aliases are added to the IndexAliasesService. The processing carried out by the IndicesClusterStateService is done within a synchronized block so I was wondering if this could be contributing to the slow-down we're experiencing? Are the InternalClusterService and IndicesClusterStateService shared across all indices on a single node? Is it possible that a large number of alias requests could cause a backlog of ClusterStateUpdateTasks in the InternalClusterService? Cheers, Paul On Tuesday, 2 April 2013 09:59:29 UTC-7, [paul.m...@globalrelay.com](mailto:paul.m...@globalrelay.com) wrote: > Thanks Alexander. > > Should be possible to test the latest code on our server. I'll give it a > whirl and see if things improve. > > Cheers, > Paul > > On Tuesday, 2 April 2013 00:18:10 UTC-7, Alexander Reelsen wrote: > > > Hey Paul, > > > > this looks really strange. There is a recent change about aliases > > processing in the master branch. Is it possible for you to test this? > > For more info see > > > > [Optimize aliases processing · Issue #2832 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/2832) > > > > [Optimize aliases processing · elastic/elasticsearch@b657bdf · GitHub](https://github.com/elasticsearch/elasticsearch/commit/b657bdfa1a9467848cc1844b5c732087e5eae1ca) > > > > On Thu, Mar 28, 2013 at 7:43 PM, [paul.m...@globalrelay.com](mailto:paul.m...@globalrelay.com) wrote: > > > > > Hi, > > > > > > we've recently started using Elasticsearch within our application and > > > are experiencing slow response times when creating aliases. We've adopted > > > the 'users data flow' model described in this presentation - > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/videos/big-data-search-and-analytics/) - > > > and are generating filtered aliases for each user in the system. > > > > > > As part of our automated test process we are creating a number of new > > > users in a short space of time. This, in turn, triggers the generation of > > > new indices within Elasticsearch and this is where we are experiencing > > > unexpected delays. For example, during a recent test run we created 44 new > > > aliases within a 70 second period. The time taken for these operations to > > > complete began at around 2 seconds but had dropped off to 69 seconds by the > > > end. This represents a particularly extreme case, but response times of > > > over 20 seconds are quite common. Generally the pattern is the same. > > > Response times will be good to start with and then gradually degrade as > > > more requests are sent. > > > > > > In terms of our set-up, we have a single Elasticsearch node shared > > > between multiple (~8) environments. Each environment has a separate index > > > with 5 shards allocated to it. Our largest shards are storing around 2 > > > million documents, all of which are reasonably small. > > > > > > My questions are: > > > > > > - Is this kind of behaviour expected when attempting to create > > > multiple aliases in a relatively short space of time? > > > - Are there any settings that we can experiment with to improve > > > performance? > > > - Is this likely to be a side effect of our current architecture > > > (i.e. sharing a single node between several environments)? > > > - What are the most useful stats that we can monitor on the server > > > to help diagnose the cause of the delays? > > > > > > Any insight you can offer will be greatly appreciated. > > > > > > Thanks, > > > Paul > > > > > > -- > > > 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](mailto:elasticsearc...@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:** ![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:41am UTC](https://discuss.elastic.co/t/performance-tuning-for-alias-creation/11364/5 "2017-07-06T02:41:29Z")