multithreading - Ets读取并发调整

Question

我正在玩ets调整，尤其是read_concurrency。我已经编写了简单的测试来衡量这种调整对读取性能的影响。测试实现为here和there。

简而言之，此测试顺序创建了三个具有不同[public, set]选项的read_concurrency ets表(无任何调整，{read_concurrency, true}和{read_concurrency, false})。创建一个表后，测试将运行N阅读器(N是2的幂，从4到1024)。然后，读取器将执行10秒钟的随机读取，并报告他们执行了多少次读取操作。

结果对我来说是非常令人惊讶的。这3个测试之间绝对没有区别。这是测试结果。

Non-tweaked table
4 workers: 26610428 read operations
8 workers: 26349134 read operations
16 workers: 26682405 read operations
32 workers: 26574700 read operations
64 workers: 26722352 read operations
128 workers: 26636100 read operations
256 workers: 26714087 read operations
512 workers: 27110860 read operations
1024 workers: 27545576 read operations
Read concurrency true
4 workers: 30257820 read operations
8 workers: 29991281 read operations
16 workers: 30280695 read operations
32 workers: 30066830 read operations
64 workers: 30149273 read operations
128 workers: 28409907 read operations
256 workers: 28381452 read operations
512 workers: 29253088 read operations
1024 workers: 30955192 read operations
Read concurrency false
4 workers: 30774412 read operations
8 workers: 29596126 read operations
16 workers: 24963845 read operations
32 workers: 29144684 read operations
64 workers: 29862287 read operations
128 workers: 25618461 read operations
256 workers: 27457268 read operations
512 workers: 28751960 read operations
1024 workers: 28790131 read operations

因此，我想知道应该如何实现测试以发现任何差异并实现此优化的用例？

我已经在以下安装上运行了该测试:

2核，1个物理CPU，Erlang/OTP 17 [erts-6.1] [64位] [smp:2:2] [异步线程:10] [hipe] [kernel-poll:false](示例测试输出来自此运行)

2核，1个物理CPU，Erlang/OTP 17 [erts-6.1] [64位] [smp:2:2] [异步线程:10] [hipe] [kernel-poll:true]

8核1物理CPU，Erlang/OTP 17 [erts-6.4] [源] [64位] [smp:8:8] [异步线程:10] [hipe] [kernel-poll:false]

8核1物理CPU，Erlang/OTP 17 [erts-6.4] [源] [64位] [smp:8:8] [异步线程:10] [hipe] [kernel-poll:true]

64核4物理CPU，Erlang/OTP 17 [erts-6.3] [源代码] [64位] [smp:64:64] [异步线程:10] [hipe] [kernel-poll:false]

64核4物理CPU，Erlang/OTP 17 [erts-6.3] [源代码] [64位] [smp:64:64] [异步线程:10] [hipe] [kernel-poll:true]

都是一样的(当然，绝对测量值除外)。
那么有人可以告诉我为什么吗？我应该怎么做才能看到有什么不同？

UPD
根据弗雷德的回答，我已更新 my test以避免邮箱工作人员崩溃。不幸的是，结果没有重大变化。

UPD
根据@Pascal的建议执行 One another。现在，所有 worker 都在适本地播种他们的随机发电机。同样的结果。

Answer 1

工作的首当其冲可能是测试节点的调度能力-在基准测试中完成的工作几乎有一半是在轮询邮箱以确定是否应该退出。这通常需要VM切换每个进程，将其放入队列，运行其他进程，检查其邮箱等。这样做很便宜，但是读取ETS也是这样。很可能会产生很多噪音。

另一种尝试方法是要求所有工作人员在表中最多读取N一百万次，并计算完成所有操作之前需要花费多长时间。这将减少在您的节点上完成的非ETS工作的数量，而只专注于从表中读取数据。

我没有任何保证，但是我敢打赌并发性更高的表将获得更快的运行速度。