# Spreading expensive aggregations over a multi search, is it faster? **URL:** \ **Category:** Elasticsearch\ **Created:** [January 13, 2016, 9:29pm UTC](https://discuss.elastic.co/t/spreading-expensive-aggregations-over-a-multi-search-is-it-faster/39161 "2016-01-13T21:29:43Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![andricDu](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andricdu/32/7141_2.png) [@andricDu](https://discuss.elastic.co/u/andricDu)\ **Post date:** [January 13, 2016, 9:29pm UTC](https://discuss.elastic.co/t/spreading-expensive-aggregations-over-a-multi-search-is-it-faster/39161/1 "2016-01-13T21:29:43Z")
Hi! I was wondering if there is any benefit in spreading aggregations into their individual searches as part of a multi search as opposed to bundling them up as part of a single query? More precisely, will all the queries and their aggregations try to run in parallel when part of a multi search? So instead of Search(filter, aggs1, aggs2, ... aggsN) we have MultiSearch[(filter, aggs1), (filter, aggs2), ... (filter, aggsN)]. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [January 14, 2016, 6:20am UTC](https://discuss.elastic.co/t/spreading-expensive-aggregations-over-a-multi-search-is-it-faster/39161/2 "2016-01-14T06:20:19Z")
> [@andricDu](#): > > I was wondering if there is any benefit in spreading aggregations into their individual searches as part of a multi search as opposed to bundling them up as part of a single query? I can't see why to be honest. You'd need to "merge" the results manually in your app code to get the same thing, which seems like more work. > [@andricDu](#): > > More precisely, will all the queries and their aggregations try to run in parallel when part of a multi search? Yep. What makes you ask this? ---
**Author:** ![andricDu](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andricdu/32/7141_2.png) [@andricDu](https://discuss.elastic.co/u/andricDu)\ **Post date:** [January 14, 2016, 2:46pm UTC](https://discuss.elastic.co/t/spreading-expensive-aggregations-over-a-multi-search-is-it-faster/39161/3 "2016-01-14T14:46:23Z")
We have some pretty gnarly query times right now for generating our aggregations. Individual aggregations are taking multiple seconds to finish. So say we have a query that spits out some aggregations. Lets say it took ~40s to compute 6 aggregations. I'm investigating and trying to verify if instead having a single filtered query with 6 aggregations we have 6 filtered queries with 1 aggregation each in a multi search. The real question is, does a filtered query with a bunch of aggregations run those aggregations in parallel anyways? If so then I lose any performance benefit I would have had with the multi search. Our prod ES cluster is v1.4.4 As for merging the results, computationally it is trivial when compared to the total time to compute a single aggregation. Some early numbers I've been generating does show a multisearch being faster, but I want to confirm the expected behaviour of a regular search in case the numbers I'm seeing are bogus due to caching/server load/networking issues/... etc ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [January 14, 2016, 9:53pm UTC](https://discuss.elastic.co/t/spreading-expensive-aggregations-over-a-multi-search-is-it-faster/39161/4 "2016-01-14T21:53:40Z")
> [@andricDu](#): > > Our prod ES cluster is v1.4.4 Upgrading will improve performance, that's a pretty easy win if you can get it. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 11:24pm UTC](https://discuss.elastic.co/t/spreading-expensive-aggregations-over-a-multi-search-is-it-faster/39161/5 "2017-07-05T23:24:19Z")