[
https://issues.apache.org/jira/browse/IGNITE-22977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-22977:
---------------------------------------
Description:
Tx mapping phase has some deficiencies, discovered during tracing, which need
to be addressed.
* HybridClockImpl uses currentTimeMillis on each update. This call is heavy,
better use FastTimestamps with 1 millisecond resolution.
* CompletableFuture has unexpected latency issues:
** onTimeout add 4-5 us of latency
** chaining adds 0.5-1 us of latency. instead of using
CompletableFuture.completedFuture(val).handle(closure) better to use if
(fut.isDone()) closure();
* Metadata validation {{{}validateTableExistence{}}},
{{{}validateSchemaMatch{}}}, {{{}waitForSchemasBeforeReading{}}}should wait
only once.
* Number of shared memory access (like updating some counter) should be
reduced. For example index rebuilding uses counters per each txn and operation.
* BinaryRow generation is 2x slower than BinaryObject in AI2: 5us vs 10us
* Thread switching brings a lot of latency. Using green threads may give a
benefit.
* RAFT command is completed always in partitions thread pool
* Number of {{clockService.now()}} calls could be reduced.
* Each tx lock cost 2us. Might be improved to 1us.
* Lease checking adds waiter even if not necessary.
* Row id generation uses randomUUID which is heavy.
was:
Tx mapping phase has some deficiencies, discovered during tracing, which need
to be addressed.
* HybridClockImpl uses currentTimeMillis on each update. This call is heavy,
better use FastTimestamps with 1 millisecond resolution.
* CompletableFuture has unexpected latency issues:
** onTimeout add 4-5 us of latency
** chaining adds 0.5-1 us of latency. instead of using
CompletableFuture.completedFuture(val).handle(closure) better to use if
(fut.isDone()) closure();
* Metadata validation {{{}validateTableExistence{}}},
{{{}validateSchemaMatch{}}}, {{{}waitForSchemasBeforeReading{}}}should wait
only once.
* Number of shared memory access (like updating some counter) should be
reduced. For example index rebuilding uses counters per each txn and operation.
* BinaryRow generation is 2x slower than BinaryObject in AI2: 5us vs 10us
* Thread switching brings a lot of latency.
* RAFT command is completed always in partitions thread pool
* Number of {{clockService.now()}} calls could be reduced.
* Each tx lock cost 2us. Might be improved to 1us.
* Lease checking adds waiter even if not necessary.
* Row id generation uses randomUUID which is heavy.
> Reduce latency for txn preparing phase
> --------------------------------------
>
> Key: IGNITE-22977
> URL: https://issues.apache.org/jira/browse/IGNITE-22977
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Alexey Scherbakov
> Assignee: Alexey Scherbakov
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tx mapping phase has some deficiencies, discovered during tracing, which need
> to be addressed.
> * HybridClockImpl uses currentTimeMillis on each update. This call is heavy,
> better use FastTimestamps with 1 millisecond resolution.
> * CompletableFuture has unexpected latency issues:
> ** onTimeout add 4-5 us of latency
> ** chaining adds 0.5-1 us of latency. instead of using
> CompletableFuture.completedFuture(val).handle(closure) better to use if
> (fut.isDone()) closure();
> * Metadata validation {{{}validateTableExistence{}}},
> {{{}validateSchemaMatch{}}}, {{{}waitForSchemasBeforeReading{}}}should wait
> only once.
> * Number of shared memory access (like updating some counter) should be
> reduced. For example index rebuilding uses counters per each txn and
> operation.
> * BinaryRow generation is 2x slower than BinaryObject in AI2: 5us vs 10us
> * Thread switching brings a lot of latency. Using green threads may give a
> benefit.
> * RAFT command is completed always in partitions thread pool
> * Number of {{clockService.now()}} calls could be reduced.
> * Each tx lock cost 2us. Might be improved to 1us.
> * Lease checking adds waiter even if not necessary.
> * Row id generation uses randomUUID which is heavy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
