IMPORTANT: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
current release documentation.
Profiling Considerations
editProfiling Considerations
editPerformance Notes
editLike any profiler, the Profile API introduces a non-negligible overhead to search execution. The act of instrumenting
low-level method calls such as collect, advance and next_doc can be fairly expensive, since these methods are called
in tight loops. Therefore, profiling should not be enabled in production settings by default, and should not
be compared against non-profiled query times. Profiling is just a diagnostic tool.
There are also cases where special Lucene optimizations are disabled, since they are not amenable to profiling. This 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.
Limitations
edit- 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 never designed to be exposed in this manner, and so all results should be viewed as a best effort to provide detailed diagnostics. We hope to improve this over time. If you find obviously wrong numbers, strange query structures or other bugs, please report them!