[ 
https://issues.apache.org/jira/browse/IGNITE-22835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911413#comment-17911413
 ] 

Alexey Scherbakov commented on IGNITE-22835:
--------------------------------------------

Implemented shared distruptor (single queue for all events) and benchmarked 
this after merging recent main (rev b2edb816b85e057abb8bb688af6549b309f8a1cb)

32 writer threads

Results are:

# shared=false logit=true

Benchmark                 (batch)  (fsync)  (partitionCount)   Mode  Cnt       
Score       Error  Units
UpsertKvBenchmark.upsert        1    false                32  thrpt   20  
212379.795 ± 28700.643  ops/s

# shared=true logit=false

Benchmark                 (batch)  (fsync)  (partitionCount)   Mode  Cnt       
Score       Error  Units
UpsertKvBenchmark.upsert        1    false                32  thrpt   20  
123629.541 ± 11835.884  ops/s

# shared=true logit=true

Benchmark                 (batch)  (fsync)  (partitionCount)   Mode  Cnt       
Score       Error  Units
UpsertKvBenchmark.upsert        1    false                32  thrpt   20  
262326.805 ± 35990.099  ops/s

# shared=false logit=false

Benchmark                 (batch)  (fsync)  (partitionCount)   Mode  Cnt       
Score       Error  Units
UpsertKvBenchmark.upsert        1    false                32  thrpt   20  
167142.261 ± 15218.456  ops/s

Summary: this optimization shines only with logit log storage, so we need to 
productize it first before merging this.

 

 

> Latency penalty for using disruptor threads
> -------------------------------------------
>
>                 Key: IGNITE-22835
>                 URL: https://issues.apache.org/jira/browse/IGNITE-22835
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Vladislav Pyatkov
>            Assignee: Alexey Scherbakov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Motivation
> All three disruptors are part of the RAFT implementation. Each time a command 
> has to be replicated, all the disruptors are used. This leads to a bad impact 
> on the entire operation's latency.
> {noformat}
> onBeforeApplyCmd:%node_3344%JRaft-Request-Processor-3 0.2 5415400 5415600
>     Here is hidden 6.1 us
> RaftNodeOnEvent:%node_3344%JRaft-NodeImpl-Disruptor_stripe_2-0 0.0 5421700 
> 5421700
> --
> RaftNodeOnEvent:%node_3344%JRaft-NodeImpl-Disruptor_stripe_2-0 0.0 5421700 
> 5421700
>     Here is hidden 2.8 us
> LogManagerOnEvent:%node_3344%JRaft-LogManager-Disruptor_stripe_2-0 0.1 
> 5424500 5424600
> --
> flushLog:%node_3344%JRaft-LogManager-Disruptor_stripe_2-0 18.7 5426400 5445100
>     Here is hidden 2.9 us
> FSMCallerOnEvent:%node_3344%JRaft-FSMCaller-Disruptor_stripe_1-0 0.1 5448000 
> 5448100
> {noformat}
> h3. Definition of done
> * We can try to use the disruptor wait policy, depending on the case.
> * Maybe we can reduce a number of the dusruptor queues.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to