Exercise 1: Two Slow Servers, One Fast — Possible Solution ==================================================================== THE CHANGE ------------------------------ Replaced this chapter's own two-fast/one-slow setup with two-slow (capacity 2/tick each) and one fast (capacity 5/tick) - total system capacity dropped from 12/tick (2+5+5, matching this chapter's own 12-requests-per-tick arrival rate exactly) to 9/tick (2+2+5), while the arrival rate stayed at 12/tick. RESULTS ------------------------------ Round Robin - final: {'slow1': 40, 'slow2': 40, 'fast1': 0} | max slow1 queue: 40 Least Connections - final: {'slow1': 22, 'slow2': 21, 'fast1': 18} | max slow1 queue: 22 DOES LEAST CONNECTIONS STILL KEEP QUEUES BOUNDED? AN HONEST NO ------------------------------ Unlike this chapter's own original scenario, Least Connections did NOT keep the slow servers' queues capped this time - slow1 reached 22 and was still growing when the simulation ended, not the bounded value of 3 this chapter's own matched-capacity scenario produced. This is because total system capacity (9/tick) is now genuinely less than the arrival rate (12/tick) - 3 more requests arrive every tick than the system can EVER process, regardless of which balancer is used. No routing algorithm can keep queues bounded when the system as a whole is oversubscribed; queues WILL grow somewhere, forever, until arrivals slow down or capacity increases. WHAT LEAST CONNECTIONS DID INSTEAD ------------------------------ Even though it couldn't prevent growth, Least Connections distributed that unavoidable backlog far more evenly than Round Robin did. Round Robin concentrated the entire backlog onto the two slow servers (40 and 40) while leaving the fast server completely idle (0) - the worst possible outcome, since the one server with spare capacity received no extra help at all. Least Connections spread the same total backlog across all three servers roughly proportionally to their own remaining capacity (22, 21, 18) - the fast server, despite having 2.5x the capacity of either slow server, still ended up carrying a comparable share of the queue, because Least Connections kept routing new requests to whichever server was currently least backed up, including the fast one, right up until it too became saturated. WHY THIS WORKS AS AN ANSWER ------------------------------ The scenario is built by directly modifying this chapter's own capacity values, the result is compared honestly against this chapter's own original bounded-queue finding rather than assumed to replicate it, and the actual underlying reason (system-wide oversubscription, not a balancer weakness) is identified precisely rather than treated as a contradiction of this chapter's own claims.