Multi thread approach vs Akka actor model

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.

This is largely dependent on your actor(system) configuration, but in all likelihood you're going to have twenty actors sitting behind a common router (e.g. a RoundRobin router or a SmallestMailbox router) and ten threads in a ThreadPoolExecutor dispatcher in which case your Akka server is going to behave similarly to your traditional server - there will be differences in how an actor is implemented vs. how a Runnable or Callable would be implemented in the traditional server, but in either case you're going to have a pool of twenty workers running on a pool of ten threads.