What trains and servers have in common - bandwidth

Practising deduction and investigation with my kids I raised the question: " Does a MRT station need more entry or exit gates?" (MRT is Singapore's local train/subway operator). So we came up with:

• People reach the station at their own time, but together in a train, so much less people will at any given time want to enter concurrently than want to leave concurrently
• unless of course the station caters to an event, where visitors leave at the end and want to enter the station
• Depending on the time of day streams might be reversed. From 8am to 9am everybody wants to leave at the Central Business District stations, while 17:00 onwards they want to enter
• Depending on the frequency of trains and the gate capacity you need more holding area in the station. If you increase the frequency of the trains too much you won't get enough people through the gates in time to fill them
• How fast can one individual pass the gate (a.k.a access latency)?

MRT solved that dilemma by having gates that can be switched on demand and once the ticket presentation at the gate (we use contactless tickets) exceeds a certain frequency the gates switch to an "stay open" mode which allows passing through at almost walking speed. In Munich there are no gates, you even could run in, but that invites to cheating and the city of Munich has a team of people randomly checking tickets on trains which always feels akward.

Similar considerations are needed in server design:

• Like in a train system (where you have: train capacity, train frequency, station capacity, gate/platform thruput, access path capacity etc.) a server system has CPU speed, CPU throughput, Cache capacity, storage throughput (commonly referred to as storage I/O) and network throughput (using Ethernet and its CSMA/CD protocol throughput declines with number of network participants, this is why we have all these expansive switches)
• Increasing the memory bandwidth by moving from 32 to 64 Bit doesn't make a system faster (your car doesn't get faster because your lanes widen from 2 to 4), but more able to handle higher demands e.g. with concurrent access or larger reads. It is like switching from a 2.8T lorry (truck for the American readers) to a 8T truck. Both are (in Germany by law) limited to a top speed of 80 km/h, but when you move the later does only need to make the distance once. Of course if your system was memory-bus or memory challenged in the first place 64Bit will help instantly
• Your CPU gets pretty bored (trains stay empty) if you can't get data in and out fast enough. What I see a lot are blade centers, virtual machine clusters or private clouds that have abundant CPU, so-so network bandwidth and (almost criminally) lacking storage I/O capabilities (not this one). This might relate to past memories where CPU tended to be the bottleneck (often today when a CPU maxes out it is due to I/O wait cycles)
• Data in and out both covers storage as well as network access. And the question How much bandwidth does a Domino server need? still missed the part "for this amount and type of payload and that response time expectation". If your network bandwidth doesn't scale, you can still change strategy

In conclusion: Your first order when planning a server, a virtual environment or a cloud:

As usual YMMV