Downloaded 315 times
Uploaded bySimon Willison
Evented I/O based web servers, explained using bunnies
The document discusses evented I/O based web servers, illustrated through a metaphor of bunnies and hamsters handling web requests. It contrasts single-threaded and multi-threaded approaches, highlighting the blocking nature of certain operations and suggesting callback methods for non-blocking code. The use of a hyperactive squid in the metaphor represents an event loop that efficiently manages long-running I/O operations.
In this document
Powered by AI
Introduction to event-driven I/O based web servers using bunnies as a metaphor.
Single-threaded server handling one request at a time, represented by a bunny with hamster users.
Using multiple threads (bunnies) to manage multiple requests simultaneously, but highlighting blocking issues with I/O.
Demonstration of multiple long-running operations causing request queuing, emphasizing the impatience of hamsters.
Transition to an event loop model using a squid to handle requests asynchronously without blocking.
Illustration of bad code that blocks the event loop, causing delays in processing requests.
Illustration of good non-blocking code using callbacks to maintain responsiveness in the event loop.
More Related Content
Similar to Evented I/O based web servers, explained using bunnies
Evented I/O based web servers, explained using bunnies
- 1. Evented I/O basedweb servers, explained using bunnies Simon Willison Part of a talk given at Full Frontal 2009
- 2. Your Web Server (using a bunny)
- 3. Your Web Server (using a bunny) Single threaded (one bunny), so can only handle one request at a time Happy hamster
- 4. Your Web Server (using a bunny) (The hamsters are using web browsers to visit your site) Impatient hamsters
- 5. Your Web Server 5bunnies = can handle 5 requests at the same time (using threads, aka bunnies) Happy hamsters
- 6. fetching a webAPI (2 seconds) Long running operations cause a thread to block, causing requests to build up in a queue Your Web Server (using threads, aka bunnies)
- 7. fetching a webAPI (2 seconds) uploading an image (3 seconds) fetching a web API (2 seconds) fetching a web API (2 seconds) comet long polling (10 seconds) Impatient hamsters
- 8. Replace the bunnieswith a single hyperactive squid. The squid runs up and down as fast as it can dealing with each hamster in turn. It ďŹres off any Your Web Server long running I/O operations and then moves on to the next hamster. When (event loop, aka the I/O operation reports progress, it hyperactive squid) does a little more work on behalf of the corresponding hamster.
- 9. Bad code ⢠rows= database.fetch(category = 'news') ⢠template = read_ďŹle('homepage.html') ⢠json = fetch_url('http://.../') These functions block and wait for results - blocking the squid and causing the entire event loop (and hence server) to pause until they complete
- 10. Good code ⢠database.fetch(category= 'news', callback) ⢠read_ďŹle('homepage.html', callback) ⢠fetch_url('http://.../', callback) These functions specify a callback to be executed as soon as the I/O operation completes