[
https://issues.apache.org/jira/browse/IGNITE-20869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20869:
---------------------------------------
Attachment: screenshot-1.png
> CompletableFuture with orTimeout has noticeable performance impact
> ------------------------------------------------------------------
>
> Key: IGNITE-20869
> URL: https://issues.apache.org/jira/browse/IGNITE-20869
> Project: Ignite
> Issue Type: Improvement
> Reporter: Kirill Gusakov
> Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png
>
>
> h3. Motivation
> [This
> |https://github.com/apache/ignite-3/blob/82c74598b5006ea3e4e86da744a68022dd799c89/modules/network/src/main/java/org/apache/ignite/network/DefaultMessagingService.java#L254-L255]line
> of code cost us near the 3us from the 26us of the whole query (~10%). The
> reason is the orTimeout(...) call.
> The simple switch to the simple new CompletableFuture() gives us a 10% boost
> from 26us/s to 23us/s in the 1-node fsync=false run of SelectBenchmark.kvGet.
> {code}
> responseFuture.orTimeout(timeout, TimeUnit.MILLISECONDS);
> {code}
> The code spends 3 microseconds or more.
> The note above is absolutely correct and appropriate for put operation as
> well.
> Next, I want to notice all the places where `orTimeput` is used in the hot
> path:
> * _LeaseTracker#awaitPrimaryReplica_ Althogh at this place, the future
> usually is completed, we call `orTimout` in any way.
> * _DefaultMessagingService#invoke0_ It is not a network timeout (despite the
> fact that it is set in the network layer), but this is an important timeout
> for application code.
> * _IgniteRpcClient#invokeAsync_ Raft retry timeout is set here.
> * _TcpClientChannel#serviceAsync_ Thin cluient operation timeout.
> h3. Definition of done
> `orTimeout` method is not used in the operation hot (put/get e.t.c) path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
