leizhiyuan opened a new issue, #1459: URL: https://github.com/apache/rocketmq-clients/issues/1459
### 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 Every RPC (send, receive, ack, heartbeat, ...) signs its metadata with the current time ([session.rs#L327-L332](https://github.com/apache/rocketmq-clients/blob/e90ece7a/rust/src/session.rs#L327-L332)): ```rust let date_time_result = OffsetDateTime::now_local(); let date_time = if let Ok(result) = date_time_result { result } else { OffsetDateTime::now_utc() }; ``` `time` 0.3 only computes the local offset when it can prove the process is single-threaded: on Linux, every `now_local()` reads and parses `/proc/self/stat` (`num_threads::is_single_threaded`). A Tokio client is always multi-threaded, so the call always fails and falls back to `now_utc()`. Each request pays one file read for nothing; the header value is UTC anyway. Java signs with UTC as well (`Signature#DATE_TIME_FORMAT = "yyyyMMdd'T'HHmmss'Z'"`). ### Steps to Reproduce Time `OffsetDateTime::now_local().unwrap_or_else(|_| OffsetDateTime::now_utc()).format(&Rfc3339)` in a process with a few threads, and send messages with 32 concurrent senders. ### What Did You Expect to See? Signing costs well under a microsecond. ### 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. | | before | after | |---|---|---| | date-time header, per call (micro-benchmark, process with 5 threads, 3 × 200k calls) | 13.9–14.1 µs | **0.34 µs** (**41×**) | | `Producer::send`, normal messages, 32 senders: msg/s | 27,120 [27311, 27120, 26957] | **29,464** [29464, 30088, 29194] (**+8.6%**) | | same: send latency p50 / p99 | 1,136 / 2,151 µs | **1,041 / 2,028 µs** | | `Producer::send`, lite messages, 32 senders: msg/s | 27,427 [27427, 27396, 27496] | **29,737** [30019, 29178, 29737] (**+8.4%**) | | `SimpleConsumer`, 16 tasks receive(32) + ack each, RTT 2 ms: msg/s | 4,306 | 4,359 (+1.2%, bound by the RTT) | The value of `x-mq-date-time` and the signature do not change: both are UTC before and after. ### 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]
