- There are different architectures for web servers that result in variations in performance and resource usage, including: - Single-process, single-threaded architecture that can only handle one request at a time. Not used in production. - Multiple process, one thread per process architecture where each process handles one request. Uses more RAM than multi-threaded. - Multiple threaded architecture where a process distributes requests to a thread pool, allowing for more concurrency limited only by thread pool size. - Event-based architectures provide an alternative to threads by manually handling context switches in an event queue, allowing for more parallelism than threads. Technologies like Nginx and Node.js use this model.

1. Architecture of Web Servers
By Nicolas Vanhoren

2. Not all web
servers are
made equal
There are different types of
architecture resulting in difference
in performances and resource
usage.
But first a little bit of definitions.

3. Do you know the difference between a program and
a process ?
● A program is a bunch of code
understandable by a computer that is
located on a storage device.
● A process is a copy of a program in the
RAM of a computer that is currently
runned by that computer.
● It’s completely possible that the same
program is runned multiple times, thus
resulting in multiple concurrent
processes. It’s even a common practice.
SSD
program1
RAM
program1_1
program1_2
program1_3

4. A few facts about
processes
● They all have their own RAM allocated by
the operating system.
● They can communicate with each other
with means similar to network
connections.

5. I also heard about a thing called “Threads” ?
● They are a feature of all modern
operating systems.
● Threads allow to have multiple
threads of execution within a
single process.
● They share the same memory.
● Due to the risk of inconsistency
with sharing that same memory
they have to rely on locks.
RAM
process1
thread1 thread2 thread3

6. Now for the web servers architectures

7. One process, one thread
● Can handle only one request at
a time.
● Is very simple to implement.
● Examples: PHP dev server, a
lot of other dev servers…
● No one really uses this in
production, the inability to
handle concurrent requests
makes this model only suitable
for quick tests.
Client
Process

8. Multiple processes, one thread per process
● Each process handles one
request max at any given time.
● Number of concurrent requests
is limited by the amount of
processes.
● Relatively high usage of RAM
per max number of concurrent
requests.
● Technologies using it: PHP
Client
Process Process Process

9. Multiple threads
● The process dispatches requests
to a pool of thread.
● Number of concurrent requests
only limited by the size of the
thread pool. Each thread usually
uses less RAM than a process.
● Can be combined with multiple
processes for best of both
worlds.
● Technologies using it: Python,
Ruby, Java, .NET,...
Client
Thread Thread Thread
Process

10. Models using alternatives to
threads
Multi-threads applications are nice, but some people still
complain about their performances and limitations. That’s
why multiple technologies (Go, Erlang, Haskell, Node.js,...)
offer alternatives. Here we will focus on one specific model...

11. Event-based web servers
● An alternative to threads where the
program manually handles context
switches using an event queue.
● Generally allows more parallelism
than multiple threads and is
considered as a more efficient
alternative for a lot of applications.
(Not all.)
● Can still be combined with multi
processed or multithreaded
architectures.
● Technologies using it: Nginx, Node.js,
Python
Client
Process
Thread
Event Event Event

12. A word about WebSockets
● They are a new specification implemented on all modern browsers.
● Instead of working on a “per request” basis, they allow persistent bi-
directional connexions between a browser and a web server.
● They are immensely useful for a lot of applications (instant messaging,
collaborative applications, notifications, video games,...)
● Multi-processes architectures are almost unable to use them as each
connexion monopolize a full process persistently.
● Multi-threads architectures are not very efficient either because there is still a
limit to the number of threads on a Linux server.
● Event-based architectures are usually considered very effective to use
WebSockets.

13. Any questions?