Dubbo: Replace the map<Long,Object> in dubbo with longObjectMap

[carryxyh]

We can use longObjectMap to replace Map in dubbo to improve performance.

We need to do the following:

1. Organize the map that can be replaced
2. Perform replacement work

我们可以使用longObjectMap来替换dubbo中的Map来提升性能。

我们需要做下面的事情：

1. 整理可以替换的Map
2. 进行替换工作

[htynkn]

this work make sense, but do we have a official way to measure performance improvement? we don't have benchmark running in CI or other stable platform.

[carryxyh]

good question. At the moment we really lack the internal benchmark. I think you can add a benchmark to the module. The performance of the new submission benchmark cannot be significantly lower than the previous benchmark results. What do u think?

[water-coder]

for this issue
I want to do this job of using longObjectMap replacing LongObjectMap.
I am willing to take this task and I will start doing it.

[bpaull1981]

Can you help me with the details of the process

On Wed, Dec 12, 2018, 4:15 AM water-coder <[email protected] wrote:

for this issue
I want to do this job of using longObjectMap replacing LongObjectMap.
I am willing to take this task and I will start doing it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-dubbo/issues/2882#issuecomment-446533994,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ari7Px1gTgSlUqUHmKbJtqkXgHy7YTSUks5u4NcmgaJpZM4ZAIEY
.

[carryxyh]

@bpaull1981
Hi, seems like @water-coder has claimed this job.

@water-coder I'd like to help u to finish this.

[water-coder]

@carryxyh
OK,thx. I will try my best to do this.

[lexburner]

@carryxyh do you mean that the LongObjectHashMap is io.netty.util.collection.LongObjectHashMap<V>? I just take a look at the usage of dubbo existing code, the Map almost are java.util.concurrent.ConcurrentHashMap，but the LongObjectHashMap is not Thread Safe . How do think about it ?

[carryxyh]

@lexburner
I think we should have a benchmark about the sync long object map and concurrent map.
Personally think the concurrent map is better, but we should have a benchmark about this two cases.
The person who claimed this task will go to the benchmark, we have already passed the mail.

Another thing, maybe my description is problematic, we are going to replace longobjectmap and other maps such as intobjectmap. Not just longobjectmap.

And the longobjectmap and intobjectmap has many impls (not just in netty). Could u give some ideas about this?

[lexburner]

LongObjectHashMap and IntObjectHashMap 无论是 netty 的实现还是像 JCtool, hppc 这样实现，据我所知，并不是为了快而诞生的，他们突出的一个特性是相比 HashMap 节约了内存的使用量，并且可能在解决 Hash 冲突方面做了一些优化，

A hash map implementation of LongObjectMap https://netty.io/4.1/api/io/netty/util/collection/LongObjectMap.html that uses open addressing for keys. To minimize the memory footprint, this class uses open addressing rather than chaining. Collisions are resolved using linear probing. Deletions implement compaction, so cost of remove can approach O(N) for full maps, which makes a small loadFactor recommended.

线性探测和链表的方式解决 Hash 冲突其实本质上是一种 trade off，在不同场景下可以说各有优势，但在实际使用场景下，比如 Dubbo，这两者的差距我觉得很难考量，或者请允许我猜测，他们的差距是微乎其微的。我个人建议是负责测试同学不能仅仅评测单机下的 micro-benchmark ，而是要在实际场景中测试两者的差距，包括 qps 和内存使用量，这工作我觉得是很大的。毕竟我们引入了第三方的依赖，需要有足够的数据佐证这样的改动是有意义的，否则，我在 benchmark 之前，会认为这样的 trade off 是我倾向于保持原样，使用原有的 HashMap。

1. Dubbo 场景中大量的 Map，这里的 Long 主要是 requestId，在并发请求中，需要快速 put, get , remove ，应该还是需要 focus 在并发性能方面，而非内存占用，所以 synchronized LongObjectHashMap 意义不是很大。
2. 数据需要长期存在于内存中的场景，LongObjectHashMap 有其存在的意义，例如 dubbo 的一些服务元数据，方法信息等等，他们不需要频繁变更，却需要长期占据内存，这比较适合使用新增的 Map 数据结构。

我的观点是主要围绕上述两点去展开工作。

另外，如果想要替换 ConcurrentHashMap，可以测评下 JCtools 的并发 Map，据称是比 jdk 更强。

Last, 这样的 issue 非常有意义，我会持续跟进

English：pls copy the above Chinese issue to google translation ，forgive my laziness, hhh.

在 2018年12月19日，上午10:48，时无两丶 [e-mail] 写道：

@lexburner https://github.com/lexburner
I think we should have a benchmark about the sync long object map and concurrent map.
Personally think the concurrent map is better, but we should have a benchmark about this two cases.
The person who claimed this task will go to the benchmark, we have already passed the mail.

Another thing, maybe my description is problematic, we are going to replace longobjectmap and other maps such as intobjectmap. Not just longobjectmap.

And the longobjectmap and intobjectmap has many impls (not just in netty). Could u give some ideas about this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/apache/incubator-dubbo/issues/2882#issuecomment-448450044, or mute the thread https://github.com/notifications/unsubscribe-auth/AK9DJuvwRqLIKU8uNM_GgnGxeO9WrRH3ks5u6ajsgaJpZM4ZAIEY.

[water-coder]

@lexburner I think your comments are very direct. At present, the stand-alone test, longObjectMap and hashMap in the number of puts reached a million level, the performance gap is very large, you said the thread safety problem, concurrent performance and memory testing, it is indeed should consider and come up with accurate evidence to support. There are also tests of actual scenes that are more convincing.