Multi thread approach vs Akka actor model

Question

I'm new to akka actor. I have read the akka offical documents and still don't understand how actor works compare to threading model.

Let's take a simple example like this. I have a traditional HttpServer , which have 10 threads in the thread pools . When 20 requests are coming at the same time , the HttpServer will delegate all 10 threads in the thread pool to handle the first 10 requests and the others will be queued in the network interface to wait for the thread to pick up.

How will an actor-based HttpServer react to the same problem?. Will all of the requests are queued in front of a delegated actors to process them in a sequential order and send the messages to other actor?. If so, this is the point that I don't understand how can actor provide better performance than threading model, because only 1 actor process 20 requests in a sequential order can not faster than 10 thread process 20 requests concurrently.

What I am trying to understand is that how actor react when multiple requests are coming together at the same time? , not how actor process and queue the message in the mail box , it's already showed up a lot in the documents. Can someone simulate the steps how actor work in this example?

Answer 1

Let me try to give a somewhat general answer that I hope clarifies things for you at a high level.

With 10 threads and 20 requests in an HTTP service based on a ...

Typical Threading Model

Requests get assigned to a thread until the request is satisfied. The thread may block, but is not necessarily released to work on another request. A performant http server can duplicate the kind of behavior found within an actor model (message based flow through multiple threads) up until the point where user code is typically called.

A Stream / Actor Model

The digestion of requests progresses through actors handling route resolution, processing of the request, and rendering the response (as examples, results may vary). At various points along this flow a thread may be assigned to handle a different request. In theory, all 20 requests could be moving through the actor model, though only 10 will be active at any time.

A benefit with a framework such as akka-http (based on akka-streams, based on akka-actors) is that the user code can participate as a streaming element in the overall flow allowing operations that might block in a threaded model to leverage non-blocking I/O, allowing the thread to be released to another request pending resolution of the I/O. For example, the http service could well act as an RESTful client and reach out to other (perhaps multiple, in parallel, via actors) services - the thread would be released to handle other requests pending responses to such outgoing HTTP traffic.

Summary

The actor model formalizes a set of (arguably best) practices around managing threads effectively.