Open benoitc opened 7 years ago
The ets
counters are bottlenecked on a single mutex. If you're modifying a counter from multiple separate threads (e.g., the erlang processes that happen to be scheduled on separate threads), the access to the ets
counter will get serialized through a single mutex, ensuing contention.
To mitigate contention, mzmetrics
maintains separate counters for each metric, spreading them around the cache lines to avoid false sharing. This way, if you increment a counter from multiple threads, they will each increment their own counter, not contending on any shared resource.
The downside is that when you need to read the counter, you need to scan across different cachelines (up to the number of cores) to assemble the final counter value.
For workloads that are primarily write-heavy, mzmetrics
can offer 10-100x speedup on counter operations. For the read-heavy counters, where counters get read comparatively frequently to the associated writes, the performance effect might be non-existent or slightly worse than ets
counter.
what is the advantage of using mzmetrics comparedto simply using ets counters?