[Docs] Add Profile API limitations
Adding some of the limitations mentioned in
Closes
@@ -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, <<profile-limitations, amongst other things>>, 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
