diff --git a/docs/reference/search/profile.asciidoc b/docs/reference/search/profile.asciidoc index e2df59ad3f4a3..6dddc34eaabcb 100644 --- a/docs/reference/search/profile.asciidoc +++ b/docs/reference/search/profile.asciidoc @@ -6,6 +6,9 @@ WARNING: The Profile API is a debugging tool and adds significant overhead to s The Profile API provides detailed timing information about the execution of individual components in a search request. It gives the user insight into how search requests are executed at a low level so that the user can understand why certain requests are slow, and take steps to improve them. +Note that the Profile API, <>, doesn't measure +network latency, time spent in the search fetch phase, time spent while the requests spends +in queues or while merging shard responses on the coordinating node. The output from the Profile API is *very* verbose, especially for complicated requests executed across many shards. Pretty-printing the response is recommended to help understand the output @@ -834,8 +837,12 @@ There are also cases where special Lucene optimizations are disabled, since they could cause some queries to report larger relative times than their non-profiled counterparts, but in general should not have a drastic effect compared to other components in the profiled query. +[[profile-limitations]] ==== Limitations +- Profiling currently does not measure the search fetch phase nor the network overhead +- Profiling also does not account for time spent in the queue, merging shard responses on the coordinating node or +additional work like e.g. building global ordinals (an internal data structure used to speed up search) - Profiling statistics are currently not available for suggestions, highlighting, `dfs_query_then_fetch` - Profiling of the reduce phase of aggregation is currently not available - The Profiler is still highly experimental. The Profiler is instrumenting parts of Lucene that were