wang-jiahua commented on PR #10448: URL: https://github.com/apache/rocketmq/pull/10448#issuecomment-4797672662
@fuyou001 Thanks for the suggestion! > For `deleteTopicList`, I suggest reusing the existing single-topic delete path instead of maintaining a separate cleanup sequence. We ran a **broker-side A/B experiment** comparing both approaches with the same batch RPC (only the broker JAR differs): - **Variant A** (your suggestion): `deleteTopicConfigList()` loops `deleteTopicConfig()` → each call triggers `persist()` (3 × fsync per item) - **Variant B** (current): `deleteTopicConfigList()` removes all from memory, then calls `persist()` once (3 fsync total) **Server benchmark results (50 topics/groups, Producer+Consumer running at ~180k TPS):** | Metric | Variant A (loop persist) | Variant B (batch persist) | Speedup | |--------|-------------------------|--------------------------|---------| | **Topic batch delete** | 730ms | 133ms | **5.5x** | | **Group batch delete** | 397ms | 18ms | **22x** | | Producer TPS impact | 0% | 0% | — | | Producer P99 RT | 5ms | 5ms | — | | GC delta | 16 | 16 | — | The key bottleneck is `persist()` → `fsync`. Each `deleteTopicConfig()` call serializes the full config to JSON, writes to disk, then fsyncs file + directory. With 50 items, that's 150 fsync calls in Variant A vs 3 in Variant B. Both variants have zero impact on concurrent Producer/Consumer TPS and P99 RT because the delete operation completes in under 1 second either way. The difference is in the **delete operation latency itself** — important for admin tools that wait for the response. **Regarding code reuse concern:** The batch path only diverges at the `removeTopicConfig` + single `persist()` level. All other cleanup logic (queue mapping, consumer offset, pop inflight counter, timer metrics, message store) is shared and unchanged. Would appreciate your feedback! -- 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]
