The profile api currently only profiles that query and aggregation parts. It doesn't measure the fetch phase nor the network overhead. I suggest you look at those.

IMO I think there are two things to do here:

1. Potentially add a profiler for the fetch phase.
2. Document the above to avoid confusion.

@owenericsson if you have any more questions please open up a thread on discuss.elastic.co and we can dive deeper. We keep github for bugs and features requests.

Pinging @elastic/es-search-aggs

hi @bleskes ,
thanks for the reply, and also apologize for posting in the wrong place.

back to this problem

1. i have set the size to 0, so there shouldn't be the fetch overhead.
2. when i remove the "aggs" part, the time cost back to a normal level (< 100ms). So i am sure that the overhead must be from the aggs

BTW. the field type of the term aggregation i used is 'keyword', and do you think this overhead is from the GlobalOrdinals ? anyway i think it is very unlikely this overhead is from the network.

OK, that changes things (although my comments are still valid in general). I will defer for someone from the search area to pick this up.

Most likely most execution time is taken by something which is not measured by the profile, like the time it took to build global ordinals, time spent in the queue, time spent merging shard responses on the coordinating node, etc. I agree we shoud at least document this.

one more thing need attention
I created my index with 11 shards, by using a routing key which means for the Search above, only one shard owns all the result data.

Closing this with adding documentation in #36252, some other improvements to the way the Profile API works are tracked in #21073