GWphua opened a new pull request, #19518:
URL: https://github.com/apache/druid/pull/19518

   Partially addresses #19505 
   
   ### Description
   
   This PR changes `setProcessingThreadNames` from enabled-by-default to opt-in.
   
   `SpecificSegmentQueryRunner` currently renames the processing thread to 
`processing_<queryId>` around segment query execution, then restores the 
original thread name in a `finally` block. This is useful while inspecting 
thread dumps, but it also means every segment runner pays two 
`Thread.setName(...)` calls for each rename scope.
   
   #12514 added the `setProcessingThreadNames` query context after high-QPS 
testing showed that processing-thread renaming has measurable overhead for very 
quick segment scans. That PR kept renaming enabled by default, but allowed 
users to opt out by setting `setProcessingThreadNames=false`.
   
   After #15757, this previously small cost became more visible for realtime 
task queries with many hydrants, because non-bySegment realtime queries now 
wrap each hydrant with its own `SpecificSegmentQueryRunner`.
   
   What was once unnoticeable now becomes visible for realtime task queries 
with many small hydrants, where each hydrant is wrapped in a 
`SpecificSegmentQueryRunner` and the actual per-hydrant query work can be very 
small.
   
   ### Number of Thread Renames in the Peon 
   The following table shows the number of thread renaming operations before 
and after #15757 
   
   |Hydrants param | Sinks | BEFORE | AFTER |
   |-- | -- | -- | -- |
   |50 | 1 | 4 | 204 |
   |100 | 1 | 4 | 404 |
   |200 | 1 | 4 | 804 |
   
   The benchmark parameter creates N persisted hydrants. The realtime sink also 
has the current incremental hydrant, so the query sees N + 1 hydrant references.
   
   Each `SpecificSegmentQueryRunner` has two rename scopes. Each scope calls 
`Thread.setName(...)` once to rename to `processing_<queryId>` and once to 
restore the original name. So each `SpecificSegmentQueryRunner` performs four 
`setName` calls.
   
   *This also shows that if there are any other additional performance overhead 
for query degradation beside thread renaming, the effects will be more 
pronounced for higher hydrant counts.*
   
   ### PR Fix
   This PR keeps the feature available by preserving the existing query context 
key `"setProcessingThreadNames"` but changes the default to false.
   
   ## Performance Benchmark 
   
   Performance of queries for different versions:
   - Baseline: Before #15757
   - BEFORE: Before this PR
   - AFTER: After this PR
   
   Lower ms/op is better. One JMH operation == one query execution.
   
   |Query type | Hydrants | Baseline ms/op | BEFORE ms/op | AFTER ms/op | 
Before v After | Baseline v After |
   |-- | -- | -- | -- | -- | -- | --|
   |timeseries | 10 | 0.064 | 0.231 | 0.141 | 39.0% faster | 121.8% slower|
   |timeseries | 50 | 0.186 | 1.036 | 0.588 | 43.2% faster | 216.2% slower|
   |timeseries | 100 | 0.335 | 1.879 | 1.113 | 40.8% faster | 232.7% slower|
   |timeseries | 200 | 0.625 | 3.923 | 2.290 | 41.6% faster | 266.4% slower|
   |segmentMetadata | 10 | 0.120 | 0.196 | 0.084 | 57.1% faster | 29.7% faster|
   |segmentMetadata | 50 | 0.287 | 0.807 | 0.323 | 59.9% faster | 12.8% slower|
   |segmentMetadata | 100 | 0.504 | 2.428 | 0.637 | 73.8% faster | 26.5% slower|
   |segmentMetadata | 200 | 1.960 | 3.393 | 1.615 | 52.4% faster | 17.6% faster|
   |scan | 10 | 0.057 | 0.159 | 0.064 | 59.5% faster | 12.0% slower|
   |scan | 50 | 0.186 | 0.751 | 0.281 | 62.6% faster | 50.6% slower|
   |scan | 100 | 0.377 | 1.638 | 0.571 | 65.1% faster | 51.7% slower|
   |scan | 200 | 0.800 | 3.732 | 1.365 | 63.4% faster | 70.6% slower|
   |groupBy | 10 | 4.366 | 0.233 | 0.135 | 42.0% faster | 96.9% faster|
   |groupBy | 50 | 21.671 | 0.820 | 0.456 | 44.4% faster | 97.9% faster|
   |groupBy | 100 | 37.954 | 1.707 | 0.881 | 48.4% faster | 97.7% faster|
   |groupBy | 200 | 76.499 | 3.720 | 2.085 | 43.9% faster | 97.3% faster|
   
   #### Release note
   <!-- Give your best effort to summarize your changes in a couple of 
sentences aimed toward Druid users. 
   
   If your change doesn't have end user impact, you can skip this section.
   
   For tips about how to write a good release note, see [Release 
notes](https://github.com/apache/druid/blob/master/CONTRIBUTING.md#release-notes).
   
   -->
   Queries no longer rename processing threads by default.
   
   Users who rely on processing thread names in thread dumps can restore the 
old behavior per query by setting `setProcessingThreadNames=true`.
   
   <hr>
   
   ##### Key changed/added classes in this PR
    * `SpecificSegmentQueryRunner`
    * `SpecificSegmentQueryRunnerTest`
    * `query-context-reference.md`
   
   <hr>
   
   <!-- Check the items by putting "x" in the brackets for the done things. Not 
all of these items apply to every PR. Remove the items which are not done or 
not relevant to the PR. None of the items from the checklist below are strictly 
necessary, but it would be very helpful if you at least self-review the PR. -->
   
   This PR has:
   
   - [x] been self-reviewed.
      - [x] using the [concurrency 
checklist](https://github.com/apache/druid/blob/master/dev/code-review/concurrency.md)
 (Remove this item if the PR doesn't have any relation to concurrency.)
   - [x] added documentation for new or modified features or behaviors.
   - [x] a release note entry in the PR description.
   - [x] added Javadocs for most classes and all non-trivial methods. Linked 
related entities via Javadoc links.
   - [x] added unit tests or modified existing tests to cover new code paths, 
ensuring the threshold for [code 
coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md)
 is met.
   - [x] been tested in a test Druid cluster.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to