[
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.
* 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.
# 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 tx counting should be only during index rebuild.
# BinaryRow generation is 2x slower than BinaryObject in AI2: 5us vs 10us
(known issue, just for clarity)
# Thread switching brings a lot of latency (known issue, just for clarity).
Can try green threads pool to mitigate this (requires java 21).
# RAFT command is completed always in partitions thread pool
# Number of {{clockService.now()}} calls should 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
> Priority: Major
> Labels: ignite-3
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
