Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 7 ■ SERVER ARCHITECTURE
» » for worker in workers:
» » » if not worker.is_alive():
» » » » print worker.name, "died; starting replacement"
» » » » workers.remove(worker)
» » » » workers.append(start_worker(Worker, listen_sock))
First, notice how this server is able to re-use the simple, procedural approach to answering client
requests that it imports from the launcelot.py file we introduced in Listing 7–2. Because the operating
system keeps our threads or processes separate, they do not have to be written with any awareness that
other workers might be operating at the same time.
Second, note how much work the operating system is doing for us! It is letting multiple threads or
processes all call accept() on the very same server socket, and instead of raising an error and insisting
that only one thread at a time be able to wait for an incoming connection, the operating system patiently
queues up all of our waiting workers and then wakes up one worker for each new connection that
arrives. The fact that a listening socket can be shared at all between threads and processes, and that the
operating system does round-robin balancing among the workers that are waiting on an accept() call, is
one of the great glories of the POSIX network stack and execution model; it makes programs like this very
simple to write.
Third, although I chose not to complicate this listing with error-handling or logging code—any
exceptions encountered in a thread or process will be printed as tracebacks directly to the screen—I did
at least throw in a loop in the master thread that checks the health of the workers every few seconds, and
starts up replacement workers for any that have failed.
Figure 7–4 shows the result of our efforts: performance that is far above that of the single-threaded
server, and that also beats slightly both of the event-driven servers we looked at earlier.
Figure 7–4. Multi-process server benchmark
Again, given the limitations of my small duo-core laptop, the server starts falling away from linear
behavior as the load increases from 5 to 10 simultaneous clients, and by the time it reaches 15
concurrent users, the number of 10-question request sequences that it can answer every second has
fallen from around 70 per client to less than 50. And then—as will be familiar to anyone who has studied
119