[
https://issues.apache.org/jira/browse/SOLR-16986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816424#comment-17816424
]
Andrzej Bialecki edited comment on SOLR-16986 at 2/11/24 2:16 PM:
------------------------------------------------------------------
Ok. In any case, this has a bug in that it ignores all but the first time
measure when there are nested requests. [~gus] and I will look into reusing
{{ThreadStats}} if possible and fixing this in SOLR-17140 so that the CPU time
logged and the CPU time limit enforced by {{CpuQueryTimeLimit}} are consistent.
was (Author: ab):
Ok. In any case, this has a bug in that it ignores all but the first time
measure when there are nested requests. [~gus] and I will look into reusing
{{ThreadStats}} if possible and fixing this in SOLR-17140.
> Measure and aggregate thread CPU time in distributed search
> -----------------------------------------------------------
>
> Key: SOLR-16986
> URL: https://issues.apache.org/jira/browse/SOLR-16986
> Project: Solr
> Issue Type: New Feature
> Reporter: David Smiley
> Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Solr responses include "QTime", which in retrospect might have been better
> named "elapsedTime". We propose adding here a "cpuTime" to return the amount
> of time consumed by
> ManagementFactory.getThreadMXBean().[getThreadCpuTime|https://docs.oracle.com/en/java/javase/11/docs/api/java.management/java/lang/management/ThreadMXBean.html]().
> Unlike QTime, this will need to be aggregated across distributed requests.
> This work item will only do the aggregation work for distributed search,
> although it could be extended for other scenarios in future work items.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
