performance test iot-telemetry-max-rate.yaml with dispatcherMaxReadBatchSize set to 500 and 1000. compare it to the baseline (value 100). Don't do profiling.

The comparison is running in the background, so there are no results yet. It is 9 runs with no profiling, and the first baseline run started at 18:26. I'll check progress at about 18:52, and I'm
  notified as each run starts and finishes.

  How it's set up:
  - Rounds: 3 rounds of iot-telemetry-max-rate.yaml with dispatcherMaxReadBatchSize set to 100, 500 and 1000. The order rotates each round (100→500→1000, then 1000→100→500, then 500→1000→100) so
    that slow drift in the host doesn't favour one value.
  - Setting: each run sets the value with --set cluster.brokers.env.dispatcherMaxReadBatchSize=<n>. The baseline sets 100 explicitly, which is also the default in conf/broker.conf.
  - Build: all runs use one image (-Pdocker.tag=batchsize), since only a setting changes and the code doesn't.
  - Cool-down: each run waits for the CPU to cool to 50 °C before it starts.
  - Guards: the script stops if thermald becomes active or the disk has less than 15 GB free.
  - Where things are: runs are grouped under the names dispatcher-read-batch-{100,500,1000} in the shared reports root. The script is run-batchsize.sh and its log is runs.log, both in the
    scratchpad.

  Host: the host check first failed 7 of 11 checks: thermald was running, turbo was on, the governor was powersave, and swappiness and huge-page settings were off. I applied the performance-testing
  profile with the passwordless configure-perf-test-environment.sh start rule, and all 11 checks then passed. I'll run stop when the runs are done to restore your normal settings. It also wrote
  inttest.asyncprofiler.skipPerfEventTuning=true to ~/.gradle/gradle.properties, which stop removes again.

  When the runs finish, I'll check each report for correctness: every message delivered, no ordering violations, no throttling. Then I'll give you a table with the median and min–max of throughput,
  publish latency and end-to-end p50/p99 for 500 and 1000 against 100.

All 9 runs completed without profiling, 3 per setting in rotating order on master f925a25884e6. Every run was valid: all 5,000,000 messages
  delivered, with no duplicates, no ordering violations and no thermal throttling. I checked in each run's resolved config that the setting took
  effect.

  ┌─────────────────────────────┬────────────────────────┬────────────────────────────────┬────────────────────────────────┐
  │      Median (min–max)       │     100 (baseline)     │              500               │              1000              │
  ├─────────────────────────────┼────────────────────────┼────────────────────────────────┼────────────────────────────────┤
  │ Delivered throughput, msg/s │ 90,547 (89,280–91,956) │ 92,928 (89,738–93,585), +2.6 % │ 92,567 (92,432–94,663), +2.2 % │
  ├─────────────────────────────┼────────────────────────┼────────────────────────────────┼────────────────────────────────┤
  │ Publish p50                 │               1,062 ms │              1,037 ms (−2.4 %) │              1,033 ms (−2.7 %) │
  ├─────────────────────────────┼────────────────────────┼────────────────────────────────┼────────────────────────────────┤
  │ End-to-end p50              │ 1,355 ms (1,319–1,390) │              1,348 ms (−0.5 %) │              1,336 ms (−1.4 %) │
  ├─────────────────────────────┼────────────────────────┼────────────────────────────────┼────────────────────────────────┤
  │ End-to-end p99              │ 1,921 ms (1,901–1,951) │                 1,921 ms (0 %) │              1,878 ms (−2.2 %) │
  ├─────────────────────────────┼────────────────────────┼────────────────────────────────┼────────────────────────────────┤
  │ End-to-end p99.9            │               2,023 ms │              2,069 ms (+2.2 %) │                 2,022 ms (0 %) │
  └─────────────────────────────┴────────────────────────┴────────────────────────────────┴────────────────────────────────┘

  - Throughput: all three runs at 1000 were faster than every baseline run. At 500, one run fell inside the baseline's range. However, the baseline
    runs got slower over the session (92.0k, then 90.5k, then 89.3k), so part of the gap may come from timing rather than the setting.
  - Latency: the differences are within the spread between runs. At maximum rate, latency mostly reflects the 100,000 messages each producer keeps
    in flight, so it follows throughput rather than measuring the dispatcher.
  - Next step: if you want a firmer answer, we could do more repetitions and a profiled broker comparison. That would show whether larger reads
    actually lower the dispatcher's read count or CPU per message on this workload.