plokhotnyuk / Actors

  ☆ノノハ
  从*’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 thread
• Dequeueing - message handling throughput in a single thread
• Initiation - memory footprint of minimal actors and initiation time in a single thread
• Single-producer sending - throughput of message sending from external thread to an actor
• Multi-producer sending - throughput of message sending from several external threads to an actor
• Max throughput - throughput of message sending from several external threads to several actors
• Ping latency - average latency of sending of a ping message between two actors
• Ping throughput 10K - throughput of executor service by sending of a ping message between 10K pairs of actors
• Overflow 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 for akka.dispatch.ForkJoinExecutorConfigurator.AkkaForkJoinPool
• java-forkjoin-pool for java.util.concurrent.ForkJoinPool
• abq-thread-pool for java.util.concurrent.ThreadPoolExecutor with java.util.concurrent.ArrayBlockingQueue
• lbq-thread-pool for java.util.concurrent.ThreadPoolExecutor with java.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

1. 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