Concurrency (and hence speed) in Servers

The primary motivation for providing concurrency in servers is, of course, speed.

Concurrency is derived from using a 'non-queuing' model of execution, either by using a new (copy of the) server to support each client, or to provide faster, 'time-sliced' response to each client.

If no concurrency is available in the server, pending requests from new and existing clients are either blocked or refused (c.f. the listen() socket API call).

In general, clients leave their concurrency to the operating system, unless the application is sufficiently large, or time-critical, that it is the only process on a CPU and it performs its own internal scheduling.

Increased concurrency, and hence speed, is required (demanded) when:

• forming responses requires significant I/O.
• processing time is proportional to the type of request.
• application-specific, high-performance, hardware is available.

Definitions:

• iterative servers - single request at a time.
• concurrent servers - multiple 'simultaneous' requests.