Profiler results from Elixir in Action (10.2.2)

I am reading the Elixir in Action book and testing ETS page cache implementation (10.2.2) on Windows 10 Pro (i7-5820K 3.30GHz, 6 cores). I got the following results:

iex(30)> Profiler.run(EtsPageCache, 100_000)

3_225_806 reqs/sec

iex(31)> Profiler.run(EtsPageCache, 100_000, 100)

81_039 reqs/sec

@sasajuric’s results running it on a 4 core system:

iex(4)> Profiler.run(EtsPageCache, 100_000)

2_613_764 reqs/sec

iex(5)> Profiler.run(EtsPageCache, 100_000, 100)

10_568_289 reqs/sec

As you can see in concurrent case call the difference is HUGE! 80 thousand vs 10 million requests per second. I am trying to find an explanation and curious if anybody else (who read the book) tested it and what were the results?

Thanks!

maybe that link helps you

1 Like

Thank you.

I have posted the question there as well.

These are my linux results from offical elixir in action repo.

iex(1)> Profiler.run(EtsPageCache, 100_000)

729336 reqs/sec

:ok
iex(2)> Profiler.run(EtsPageCache, 100_000, 100)

5532901 reqs/sec

:ok
iex(3)>
1 Like

It appears you’re running examples from the first edition. For various reasons, these are obsolete.

My main OS is macos, but I’ve just tried the 2nd edition examples (the 2nd-edition branch) on Windows 10, quad core machine, Elixir 1.6 and Erlang 20.2. Here’s what I’ve got:

non ETS:

mix run -e "Bench.run(KeyValue)" 
245682 operations/sec

mix run -e "Bench.run(KeyValue, concurrency: 100)" 
317935 operations/sec

ETS:

mix run -e "Bench.run(EtsKeyValue)" 
1828488 operations/sec

mix run -e "Bench.run(EtsKeyValue, concurrency: 100)" 
3575259 operations/sec

For comparison, here’s what I’ve got on my macbook:

non ETS:

mix run -e "Bench.run(KeyValue)"
621003 operations/sec

mix run -e "Bench.run(KeyValue, concurrency: 1000)"
325055 operations/sec

ETS:

mix run -e "Bench.run(EtsKeyValue)"
3576332 operations/sec

mix run -e "Bench.run(EtsKeyValue, concurrency: 1000, num_updates: 100)"
16993927 operations/sec

There are clearly some differences between Windows/macos, which I currently can’t explain. One part of the reason could lie in the fact that the benchmark is synthetic, simplified, and originally performed on my macos machine. Regardless, the two main points hold across different OSes:

  • ETS implementation is much faster than non-ETS
  • ETS implementation scales better than non-ETS

Either way, your results are quite strange, since performance degrades significantly with increased concurrency. I wonder if your Erlang installation is taking advantage of multiple cores at all? What’s the result of System.schedulers and System.schedulers_online?

4 Likes

12 in both cases. I have just tested on another W10 and got same bad results.

:man_facepalming: Found the problem after running GitHub version. It was stupid error on my side. Reporting was not taking into account number of concurrent clients. :flushed:

Sorry for wasting everybody’s time.

3 Likes