Small demo to test multi vs single thread performance when converting images, using a combination of http / websockets for communicating between the client and server.

This small app applies a set of filters to an image (using scrimage library) in order to test performance in two different execution contexts. Some of the tech used:

• Play framework for the MVC backend
• Akka actor system to handle websocket communications
• BaconJS for handling websockets communications as streams

Two different thread execution contexts are tested (configuration)

Multi-Threaded: Uses the default scala fork-join-executor

multi-thread-context {
  type = Dispatcher
  executor = "fork-join-executor"
  fork-join-executor {
  }
  throughput = 100
}

Single-Threaded: Uses a thread-pool-executor restricted to 1 core.

single-thread-context {
  type = Dispatcher
  executor = "thread-pool-executor"
  thread-pool-executor {
    fixed-pool-size = 1,
    # minimum number of threads to cap factor-based core number to
    core-pool-size-min = 1
    # No of core threads ... ceil(available processors * factor)
    core-pool-size-factor = 1.0
    # maximum number of threads to cap factor-based number to
    core-pool-size-max = 1
  },
  throughput = 1
}

Because of hosting limitations, images will be wiped 5 minutes after creation

Each pageview registers a websocket connection with the backend, and the websocket identifier is linked to the user session Id. When a request for processing images comes from the user, the session ID is used to lookup the correct websocket to send the update after processing has finished.

• Due to Heroku's hosting limitations, the client must send a ping to keep the connection alive every 30 secs.