You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Taras Ledkov (JIRA)" <ji...@apache.org> on 2016/12/29 14:01:02 UTC
[jira] [Commented] (IGNITE-3018) Cache affinity calculation is slow
with large nodes number
[ https://issues.apache.org/jira/browse/IGNITE-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15785367#comment-15785367 ]
Taras Ledkov commented on IGNITE-3018:
--------------------------------------
I've implemented two realization of the rendezvous affinity function:
- One is the full compatible with current and contains several performance fix (the recommendations for this fix are described at the IGNITE-3905 by Andrey & Alex).
- Another is based on 32/64 bits Wang/Jenkins hash and build-in hashCode() for ClusterNode hash object for instead of MD5 (see above).
Also *Fair* affinity function is benchmarking together.
The results look like {{FairAffinityFunction}} provides the best performance for large nodes count.
Benchmark case: create base topology contains N nodes and change topology: add/remove one node.
|| Nodes || Fair || Rendezvous (old) || Rendezvous (compat) || FastRendezvous ||
|*10* | 9.7 ms +/- 21.020 ms | 5.6 ms +/- 3.551 ms | 5.3 ms +/- 3.674 ms | 1.4 ms +/- 1.391 ms |
|*100* | 1.1 ms +/- 2.035 ms | 52.3 ms +/- 9.569 ms | 37.0 ms +/- 8.756 ms | 5.2 ms +/- 3.468 ms |
|*200* | 0.9 ms +/- 1.202 ms | 105.8 ms +/- 8.682 ms | 75.1 ms +/- 12.888 ms | 9.0 ms +/- 4.026 ms |
|*300* | 1.5 ms +/- 2.194 ms | 163.8 ms +/- 13.147 ms | 111.8 ms +/- 14.388 ms | 14.1 ms +/- 6.257 ms |
|*400* | 2.0 ms +/- 2.447 ms | 222.2 ms +/- 15.378 ms | 146.9 ms +/- 12.616 ms | 18.9 ms +/- 7.656 ms |
|*500* | 1.1 ms +/- 1.010 ms | 283.5 ms +/- 15.329 ms | 184.5 ms +/- 12.529 ms | 22.5 ms +/- 7.070 ms |
|*600* | 4.3 ms +/- 2.887 ms | 345.2 ms +/- 19.667 ms | 223.9 ms +/- 15.834 ms | 28.2 ms +/- 8.213 ms |
> Cache affinity calculation is slow with large nodes number
> ----------------------------------------------------------
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Reporter: Semen Boikov
> Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 400.png, 500.png, 600.png
>
>
> With large number of cache server nodes (> 200) RendezvousAffinityFunction and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and nodes list sorting. As optimization we can try to cache {partion, node} MD5 hash or try another hash function. Also several minor optimizations are possible (avoid unncecessary allocations, only one thread local 'get', etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)