[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000979#comment-15000979
]
Artem Shutak commented on IGNITE-1678:
--------------------------------------
Fixed some bugs in implementation. Now all tests pass.
Benchmarking status
- I benchmarked old and new implementation only on local machine (3 clients, 2
servers)
- Current benchmark results show direct dependency between
atomicSequenceReserveSize and op/sec. Look like only number of transactions
cache op-s have meaning. Need to check it with many phisicale machines
- Need to solve with default percentage value.
Left:
- Add tests on new reserevePercetage paramether
- Create runners of GridCachePartitionedAtomicSequenceMultiThreadedTest in
another modes: replicated, transactional
- Benchmark with many phisicale machines
> IgniteAtomicSequence: make following reservations in advance
> ------------------------------------------------------------
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
> Affects Versions: ignite-1.4
> Reporter: Denis Magda
> Assignee: Artem Shutak
> Fix For: 1.6
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
