leizhiyuan opened a new issue, #1458: URL: https://github.com/apache/rocketmq-clients/issues/1458
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Programming Language of the Client Rust ### Runtime Platform Environment Linux 6.6 x86_64, 32 cores ### RocketMQ Version of the Client/Server Client: Rust `rocketmq` 5.0.0, master `e90ece7a` Server: mock proxy over real gRPC (see the test environment below) ### Run or Compiler Version rustc 1.97.1 (also checked with 1.74.0, the MSRV) ### Describe the Bug With `enable_fifo_consume_accelerator(true)`, `LitePushConsumer` still consumes a batch of lite messages one by one. The accelerator groups the messages of a batch by message group and consumes the groups in parallel ([push_consumer.rs#L988-L993](https://github.com/apache/rocketmq-clients/blob/e90ece7a/rust/src/push_consumer.rs#L988-L993)): ```rust let group = message.message_group().map(|s| s.to_string()); ``` A lite message never has a message group (the producer rejects `lite_topic` together with `message_group`), so every lite message of the batch lands in the `None` group and the accelerator has no effect. For lite messages the order to keep is per lite topic. Java groups lite messages by lite topic: `LitePushConsumerImpl#createConsumeService` creates a `LiteFifoConsumeService`, whose `getMessageGroupKey` returns `messageView.getLiteTopic()`. ### Steps to Reproduce `LitePushConsumer` with `enable_fifo_consume_accelerator(true)`, a FIFO group (the server pushes `fifo=true`), one bind-topic queue carrying 100 subscribed lite topics, a listener that takes 1 ms, receive and ack RTT 2 ms. ### What Did You Expect to See? Different lite topics consumed in parallel, the order inside each lite topic kept, like Java. ### What Did You See Instead? ### Test environment - Host: Linux 6.6 x86_64, 32 cores; rustc 1.97.1, release build. - Client: `master` `e90ece7a` ("before") vs. the PR branch rebased on it ("after"); nothing else differs. - Server: a mock RocketMQ proxy that speaks the real gRPC protocol over TCP on 127.0.0.1 (tonic 0.9, `TCP_NODELAY` like grpc-java), driven only through the public API of the client. The same harness is used for every number in #1445. Each cell: 3 runs of the same binary, median shown (all 3 runs in brackets). Absolute numbers depend on the machine and the mock; the before/after ratio is the point. | `LitePushConsumer`, FIFO, 100 lite topics on 1 queue, listener 1 ms, RTT 2 ms | before | after | |---|---|---| | accelerator **on**: consumed msg/s | 224.7 [225, 224, 225] | **1,955.2** [1952, 1967, 1955] (**8.7×**) | | accelerator off: consumed msg/s (unchanged, sequential by design) | 224.3 [226, 224, 223] | 223.4 [225, 223, 223] | With the accelerator on, `master` is exactly as fast as with it off: the batch is consumed sequentially. ### Additional Context Part of the Rust performance tracking issue #1445. -- 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]
