Ets读取并发调整

Question

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

简而言之，该测试顺序创建了三个具有不同read_concurrency选项（没有任何调整， {read_concurrency, true}和{read_concurrency, false} [public, set] ets表）的表。 创建一张表后，测试运行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

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

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

1. 2核，1个物理CPU，Erlang / OTP 17 [erts-6.1] [64位] [smp：2：2] [async-threads：10] [hipe] [kernel-poll：false]（ 示例测试输出从这个运行 ）
2. 2核，1个物理CPU，Erlang / OTP 17 [erts-6.1] [64位] [smp：2：2] [异步线程：10] [hipe] [kernel-poll：true]
3. 8核1物理CPU，Erlang / OTP 17 [erts-6.4] [源] [64位] [smp：8：8] [async-threads：10] [hipe] [kernel-poll：false]
4. 8核1物理CPU，Erlang / OTP 17 [erts-6.4] [源] [64位] [smp：8：8] [async-threads：10] [hipe] [kernel-poll：true]
5. 64核4物理CPU，Erlang / OTP 17 [erts-6.3] [源] [64位] [smp：64：64] [async-threads：10] [hipe] [kernel-poll：false]
6. 64核4物理CPU，Erlang / OTP 17 [erts-6.3] [源] [64位] [smp：64：64] [async-threads：10] [hipe] [kernel-poll：true]

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

UPD根据Fred的回答，我已经更新了我的测试，以避免邮箱工作人员摇动。 不幸的是，结果没有重大变化。

UPD根据@Pascal的建议另一个实现。 现在，所有工人都在适当地播种其随机发电机。 同样的结果。

Answer 1

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

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

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

Answer 2

我制作了代码的新版本，在此代码中，我添加了一个布尔参数来执行或跳过ets访问。 毫无疑问，大多数时间都花在了其他东西上，而不是读过的东西：

[编辑]

@Viacheslav评论后，我现在初始化表...几乎没有效果。

编码：

-module(perf).

-export ([tests/0]).

-define(TABLE_SIZE, 100).
-define(READS_COUNT, 5000000).

read_test(Doit,WkCount,NbRead,TableOpt) ->
    Table = ets:new(?MODULE, TableOpt),
    [ ets:insert(Table, {I, something}) || I <- lists:seq(1, ?TABLE_SIZE)],
    L = [erlang:now() || _ <- lists:seq(1,WkCount)],
    F = fun() -> spawn_readers(Doit,WkCount,NbRead,Table,L) end,
    {T,_} = timer:tc(F),
    ets:delete(Table),
    T.
table_types() -> 
    [[public, set, {read_concurrency, false}],[public, set, {read_concurrency, true}],[public, set]].

spawn_readers(Doit,WkCount, NbRead, Table, L_init) ->
    [spawn_monitor( fun() -> reader(Doit,NbRead, Table, X) end) || X <- L_init],
    reap_workers(WkCount).

reader(Doit,NbRead, Table, Seed) ->
    random:seed(Seed),
    reader_loop(Doit,NbRead,Table).

reader_loop(_,0,_Table) ->
    ok;
reader_loop(true,ToRead,Table) ->
    Key = random:uniform(?TABLE_SIZE),
    ets:lookup(Table, Key),
    reader_loop(true,ToRead-1, Table);
reader_loop(false,ToRead,Table) ->
    _Key = random:uniform(?TABLE_SIZE),
    reader_loop(false,ToRead-1, Table).

reap_workers(0) ->
    ok;
reap_workers(Count) ->
    receive
        {'DOWN', _, process, _, _} ->
            reap_workers(Count-1)
    end.

tests() ->
    [[{X,number_proc,Y,read_test(true,Y,?READS_COUNT div Y,X),read_test(false,Y,?READS_COUNT div Y,X)}
    || X <- table_types()] 
    || Y <- [1,10,100,1000,10000]].

结果：

8> perf:tests().
[[{[public,set,{read_concurrency,false}],
   number_proc,1,2166000,1456000},
  {[public,set,{read_concurrency,true}],
   number_proc,1,2452000,1609000},
  {[public,set],number_proc,1,2513000,1538000}],
 [{[public,set,{read_concurrency,false}],
   number_proc,10,1153000,767000},
  {[public,set,{read_concurrency,true}],
   number_proc,10,1180000,768000},
  {[public,set],number_proc,10,1181000,784000}],
 [{[public,set,{read_concurrency,false}],
   number_proc,100,1149000,755000},
  {[public,set,{read_concurrency,true}],
   number_proc,100,1157000,747000},
  {[public,set],number_proc,100,1130000,749000}],
 [{[public,set,{read_concurrency,false}],
   number_proc,1000,1141000,756000},
  {[public,set,{read_concurrency,true}],
   number_proc,1000,1169000,748000},
  {[public,set],number_proc,1000,1146000,769000}],
 [{[public,set,{read_concurrency,false}],
   number_proc,10000,1224000,832000},
  {[public,set,{read_concurrency,true}],
   number_proc,10000,1274000,855000},
  {[public,set],number_proc,10000,1162000,826000}]]