Find the bottleneck
Weekday rush hour in Timetable’s second, smaller city, which runs on its own servers and database, with heavier lookups.
20 minMediumMembers kata
Membership isn’t open yet. One kata or case is open to you now, 1 more with a free account.
The brief
Weekday rush hour in Timetable’s second, smaller city, which runs on its own servers and database, with heavier lookups. Station screens look up departures a steady 40 times a second all day. Riders’ apps send 80 a second on an average afternoon; at second 20 the rush starts and they jump to 260. Every lookup passes a load balancer to one of two large Timetable API servers, which ask the timetable database. It runs on a large server of its own with a pool of 8 connections, and each lookup holds a connection for about 30 ms. On an average afternoon all looks calm: the API servers about 31% busy, the database server about 63%, the pool about 45% in use. At second 90, in the middle of the rush, API server 2 fails and stays down; it stays a large and can’t be removed or resized. Find what runs out first at rush hour and fix every limit, for under $375 a month. A large API server answers about 150 lookups a second while staying under 80% busy, and each lookup costs the database server about as much CPU as it costs an API server. In this sim, a server kept above 95% busy for 5 seconds goes down and stays down, and above 80% it slows (up to 3× at 95%). A pool lends each lookup a connection for as long as its query runs. In this sim, once a second’s connections are spent the lookups that don’t fit fail at once (a real pool makes them wait), and a pool more than 70% in use slows its queries (2× from 90%) — leave it headroom, like a server.
What it checks
- 1For a planned peak, work out what each resource carries — CPU, connections in use, the database's total connections — and name the one that runs out first.
- 2Estimate how many servers a peak needs — the peak divided by what one server handles at a target utilization below the knee, plus enough spare to lose one.
- 3Choose a pool size that covers the peak without swamping the database, with every instance's pool together under the database's connection limit.