[
https://issues.apache.org/jira/browse/IGNITE-20869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20869:
---------------------------------------
Description:
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 also 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
was:
[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 simple new CompletableFuture() give us 10% boost from
26us/s to 23us/s in the 1-node fsync=false run of SelectBenchmark.kvGet.
> 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
>
> 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 also 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
