capistrant commented on PR #20805: URL: https://github.com/apache/druid/pull/20805#issuecomment-6534644834
> I understand that a fair critique on the benchmarks could be that all the workers are using 1 processing thread. in real scenarios where workers could be processing in parallel you will have less efficiency in segment acquires. evaluating some benchmark changes that could give more realistic results ### `DartScanBenchmark` at 8 processing threads per worker The tables in the description were measured with the benchmark harness's previous default of **one processing thread shared by all workers**. With one thread, each worker loads only 2 segments ahead and finishes every segment before the next one starts, so the skip threshold is always as tight as it can be. That makes them a best case scenario. This run uses the new `threadsPerWorker` benchmark parameter that I added in this PR. It sets each worker's processor count and sizes the shared processing pool so that every worker gets its own threads. load-ahead defaults to twice the thread count. At 8 threads, a worker starts about 25 segments before any threshold exists, and pruning takes effect after that. `a → b` is master → this branch, bold when it changes by more than 1%. A single value means no change. | Query | Layout | Limit | Segments acquired | Rows in acquired segments | Rows written | |---|---|---:|---:|---:|---:| | `orderByTimeDescWithLimit` | V9_TIME_ORDERED | 10 | 120 → **24** | 12,000,000 → **2,398,180** | 1,200 → **40.6** | | | V9_TIME_ORDERED | 10000 | 120 → **25** | 12,000,000 → **2,499,302** | 1,200,000 → **20,918** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10 | 120 → **25** | 12,000,000 → **2,497,756** | 12,000,000 → **7,340** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10000 | 120 → **25** | 12,000,000 → **2,500,000** | 12,000,000 → **74,184** | | | V10_CLUSTERED | 10 | 120 → **25** | 12,000,000 → **2,500,000** | 1,200 → **46.9** | | | V10_CLUSTERED | 10000 | 120 → **25** | 12,000,000 → **2,500,000** | 1,200,000 → **22,117** | | `orderByTimeAscWithLimit` | V9_TIME_ORDERED | 10 | 120 → **24.5** | 12,000,000 → **2,446,907** | 1,200 → **42.1** | | | V9_TIME_ORDERED | 10000 | 120 → **25** | 12,000,000 → **2,498,621** | 1,200,000 → **20,799** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10 | 120 → **25** | 12,000,000 → **2,497,398** | 12,000,000 → **7,149** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10000 | 120 → **25** | 12,000,000 → **2,499,237** | 12,000,000 → **73,706** | | | V10_CLUSTERED | 10 | 120 → **25** | 12,000,000 → **2,500,000** | 1,200 → **44.6** | | | V10_CLUSTERED | 10000 | 120 → **25** | 12,000,000 → **2,500,000** | 1,200,000 → **22,420** | | `whereClusterKeyOrderByTimeDescWithLimit` | V9_TIME_ORDERED | 10 | 120 → **24.3** | 12,000,000 → **2,430,802** | 1,200 → **43.6** | | | V9_TIME_ORDERED | 10000 | 120 → **34.2** | 12,000,000 → **3,424,317** | 121,035 → **15,614** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10 | 120 → **25** | 12,000,000 → **2,498,413** | 121,035 → **6,774** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10000 | 120 → **33.3** | 12,000,000 → **3,329,843** | 121,035 → **14,728** | | | V10_CLUSTERED | 10 | 120 → **24.6** | 12,000,000 → **2,463,610** | 1,200 → **44.8** | | | V10_CLUSTERED | 10000 | 120 → **34.3** | 12,000,000 → **3,425,260** | 121,035 → **14,882** | | `whereClusterKeyAndDimOrderByTimeDescWithLimit` | V9_TIME_ORDERED | 10 | 120 → **25** | 12,000,000 → **2,495,614** | 1,200 → **48.9** | | | V9_TIME_ORDERED | 10000 | 120 | 12,000,000 | 2,740 | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10 | 120 → **24.7** | 12,000,000 → **2,466,906** | 2,740 → **97.5** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10000 | 120 | 12,000,000 | 2,740 | | | V10_CLUSTERED | 10 | 120 → **24.9** | 12,000,000 → **2,488,144** | 1,200 → **44.1** | | | V10_CLUSTERED | 10000 | 120 | 12,000,000 | 2,740 | | `unorderedWithLimit` | V9_TIME_ORDERED | 10 | 120 | 12,000,000 | 31.8 → **31.1** | | | V9_TIME_ORDERED | 10000 | 120 | 12,000,000 | 52,480 → 52,295 | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10 | 120 | 12,000,000 | 33.1 → **31.8** | | | V10_UNCLUSTERED_CLUSTERING_ORDER | 10000 | 120 | 12,000,000 | 52,552 → 52,851 | | | V10_CLUSTERED | 10 | 120 | 12,000,000 | 36.2 → **25.7** | | | V10_CLUSTERED | 10000 | 120 | 12,000,000 | 51,939 → 51,681 | | `whereDimOrderByTimeDescNoLimit` | V9_TIME_ORDERED | none | 120 | 12,000,000 | 267,502 | | | V10_UNCLUSTERED_CLUSTERING_ORDER | none | 120 | 12,000,000 | 267,502 | | | V10_CLUSTERED | none | 120 | 12,000,000 | 267,502 | **Queries** (`n` is the `limit` parameter): - `orderByTimeDescWithLimit` / `orderByTimeAscWithLimit`: `SELECT * FROM scan_ds ORDER BY __time DESC|ASC LIMIT n` - `whereClusterKeyOrderByTimeDescWithLimit`: `SELECT * FROM scan_ds WHERE clusterKey1 = '1' ORDER BY __time DESC LIMIT n` - `whereClusterKeyAndDimOrderByTimeDescWithLimit`: `SELECT * FROM scan_ds WHERE clusterKey1 = '1' AND dimSecondary = '7' ORDER BY __time DESC LIMIT n`. It matches 2,740 rows in total, so at `LIMIT 10000` the threshold never forms and nothing can be pruned. That is the worst case for this change. - `unorderedWithLimit`: `SELECT * FROM scan_ds LIMIT n`, which exercises the refactored limit path for scans without ORDER BY. - `whereDimOrderByTimeDescNoLimit`: `SELECT * FROM scan_ds WHERE dimSecondary = '7' ORDER BY __time DESC`, the control. To reproduce: `java -jar benchmarks/target/benchmarks.jar 'DartScanBenchmark' -p numTimeChunks=30 -p numPartitionsPerTimeChunk=4 -p threadsPerWorker=8 -p layout=V9_TIME_ORDERED,V10_UNCLUSTERED_CLUSTERING_ORDER,V10_CLUSTERED -jvmArgsAppend "<flags from docs/operations/java.md>"` -- 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]
