Awesome
☆ノノハ
从*’w’)
(つactorsと)
Evaluation of API and performance of in-memory messaging for different actor implementations written on Scala: Akka vs. Lift vs. Scala vs. Scalaz
This project provides and tests alternative implementations of Minimalist actor and bounded/unbounded mailboxes for Akka: Akka vs. Minimalist Scala Actor also it provides alternative fork-join tasks which increase efficiency of actors and examples of their usage with Lift, Scala & Scalaz actors.
Benchmarks and their goals
Enqueueing
- memory footprint of internal actor queue per submitted message and submition throughput in a single threadDequeueing
- message handling throughput in a single threadInitiation
- memory footprint of minimal actors and initiation time in a single threadSingle-producer sending
- throughput of message sending from external thread to an actorMulti-producer sending
- throughput of message sending from several external threads to an actorMax throughput
- throughput of message sending from several external threads to several actorsPing latency
- average latency of sending of a ping message between two actorsPing throughput 10K
- throughput of executor service by sending of a ping message between 10K pairs of actorsOverflow throughput
- throughput of overflow handing for bounded version of actors
Hardware required
- CPU: 2 cores or more
- RAM: 6Gb or greater
Software installed required
- JDK: 1.8.0_x
- sbt: 0.13.x
Building & running benchmarks
Before benchmark running check if your CPU works in most performant mode (not a powersave one). Check it on Linux by following command:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Use following command-line instructions to build from sources and run benchmarks with Java's ForkJoinPool in FIFO mode:
sbt clean test &>outX.txt
Use sbtAll.sh
scripts (for Windows: sbtAll.bat
) to run benchmarks for the following types of executor services:
akka-forkjoin-pool
forakka.dispatch.ForkJoinExecutorConfigurator.AkkaForkJoinPool
java-forkjoin-pool
forjava.util.concurrent.ForkJoinPool
abq-thread-pool
forjava.util.concurrent.ThreadPoolExecutor
withjava.util.concurrent.ArrayBlockingQueue
lbq-thread-pool
forjava.util.concurrent.ThreadPoolExecutor
withjava.util.concurrent.LinkedBlockingQueue
Recommended values of JVM options which can be set for SBT_OPTS system variables:
-server -Xms1g -Xmx1g -Xss1m -XX:NewSize=512m -XX:+TieredCompilation -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:-UseBiasedLocking -XX:+AlwaysPreTouch
Known issues
- Benchmark freeze with Java ForkJoinPool baked by 1 thread on 8u40, 8u45, 8u51 and some early 8u60 ea builds, please see details here: https://bugs.openjdk.java.net/browse/JDK-8078490
W/A is to upgrade to latest Java 8 build (8u60-b27 or above) or to use latest jsr166.jar (link to download http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar)
in working directory with following JVM option to pick it up: -Xbootclasspath/p:jsr166.jar
Test result descriptions
Results of running sbtAll.sh scripts on different environments with pool size (or number of worker threads) set to number of available processors, 1 or 100 values accordingly:
out0.txt
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz (max 3.50GHz), RAM 16Gb DDR3-1600, Ubuntu 15.04, Linux 4.4.0-38-generic, Oracle JDK build 1.8.0_112-b15 64-bit