|
|
@@ -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
|
|
|
@@ -861,8 +864,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
|
Christoph Büscher