[
https://issues.apache.org/jira/browse/RATIS-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18078567#comment-18078567
]
Ivan Andika edited comment on RATIS-2509 at 5/6/26 2:20 AM:
------------------------------------------------------------
> As you mentioned, there are ByteString conversion. In Ozone, since OM uses
> Hadoop RPC to receive a request from the network, the ratis request is just a
> local RaftServer call (i.e. no RaftClient). So, we may add a
> OmReadOzoneMessage class in Ozone to avoid ByteString conversion:
Thanks for the idea. This might be possible, but I don't think it fully remove
the serde since OzoneManagerStateMachine#query is still doing the request
deserialization and response serialization (AbtractMessageLite#toByteString).
Correct me if I'm wrong.
was (Author: JIRAUSER298977):
> As you mentioned, there are ByteString conversion. In Ozone, since OM uses
> Hadoop RPC to receive a request from the network, the ratis request is just a
> local RaftServer call (i.e. no RaftClient). So, we may add a
> OmReadOzoneMessage class in Ozone to avoid ByteString conversion:
Thanks for the idea. This might be possible, but I don't think it fully remove
the serde since OzoneManagerStateMachine#query is still doing the request
deserialization and response serialization (AbtractMessageLite#toByteString).
> Introduce local read API to reduce serde cost
> ---------------------------------------------
>
> Key: RATIS-2509
> URL: https://issues.apache.org/jira/browse/RATIS-2509
> Project: Ratis
> Issue Type: Improvement
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
> Attachments: 1448_review.patch,
> om-benchmark-leader-read-all-ratis.html,
> om-benchmark-leader-read-no-ratis.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Recently, we did a benchmark comparing the OM leader-read that does not go
> through Ratis and OM leader read that go through Ratis (through
> submitClientRequestAsync). We saw that there is up to 25% decrease in read
> throughput although the we make the raft.server.read.option to be DEFAULT
> which should return immediately (235020 QPS -> 180433 QPS or 24% reduction in
> throughput for pure reads with 100 threads).
> The overheads seem to be because of request/response proto conversion,
> RaftClientRequest construction, future chaining, .get() blocking, Ratis
> metrics/reply building, and parsing the Ratis response back into OMResponse.
> See [^om-benchmark-leader-read-all-ratis.html] for the flamegraph.
> This means that if we submit linearizable read to follower, we incurs these
> overhead on top of the linearizable read overhead (e.g. ReadIndex, etc).
> We can try to find a way to reduce this overhead. We might need to implement
> another read flow without the overhead (unlike writes which requires
> AppendEntries request to the followers which require serde, read can be
> served locally).
> One idea is that if we are submitting to RaftServer, we can use
> submitServerRequestAsync which does not require RaftClientRequest and
> RaftClientReply serde.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
