Picking a Flexus tier by workload, not by the price tag

Last week I sat down to pick a small server for three things I actually run: a single-file 2048 demo, a personal tool site, and a small proxy relay I use for testing. I kept catching myself sorting by price first, and that was the wrong order. The cheapest tier is not a bargain if it swaps all day, and the biggest tier is not safer if the workload barely wakes up.

Start from the workload, not the tier list

I wrote down, for each service, four things: how much memory it holds when idle, what it does at peak, how long it stays busy, and what breaks first when it runs out of room. That list did more work than any comparison table.

The 2048 demo is almost nothing. It serves one static page, gets a handful of visits, and then goes quiet. It does not need much CPU, and it does not need much memory. On a small tier it loads fast and stays fast, because there is nothing competing for resources.

The personal tool site is different. It is quiet most of the day, then a few people hit it at once. CPU spikes for seconds, not hours. What matters there is not raw CPU, but having enough memory headroom that a short burst does not push the box into swap. Once swap starts, every request feels slow, and the monitoring graph looks worse than the real traffic.

The proxy relay taught me the third lesson. It is light on CPU, but it is always on. I had already learned, from an earlier relay experiment on a cloud computer, that idle behaviour matters: a machine that sleeps, throttles, or loses its address after a while is a poor relay no matter how cheap it is. For an always-on relay, stability and steady bandwidth matter more than peak CPU.

How I compare tiers in practice

First, memory before CPU. A web page, a small database, and a build job can all live on the same box in theory, but together they eat memory in a way a CPU chart hides. If I plan to run a database plus anything else, I step up a memory tier before I step up CPU.

Second, peak versus idle. A tier that looks fine at idle can fall over during a build, a backup, or a traffic spike. I check what happens during the busiest ten minutes, not the average hour.

Third, disk and bandwidth, in that order after memory. A small site does not need a large disk, but it does need enough room for logs and updates so it does not fill up quietly. And for a relay, I watch sustained throughput, not the headline number.

Fourth, the upgrade path. I would rather start small, watch a week of real use, and move up one tier than pay for a large tier on day one. Moving up is easy; paying for idle capacity all month is not refundable in any useful sense.

The three scenarios, in short

• Static demo or personal page, a few visitors, mostly idle: the smallest tier is usually enough. Spend the saved effort on a clean deployment instead.
• Personal tools with bursty traffic: pick a tier with memory headroom first. The bottleneck I have hit here is swap and contention, not a lack of cores.
• Always-on relay or small service with a database: go one step up from what looks sufficient on paper, and check idle stability, disk room, and monitoring before you trust it.

What I will do differently next time

I will not pick by price alone, and I will not pick the biggest tier just to stop worrying. I will run the real workload for a week, look at memory pressure and the busiest minutes, and only then decide whether to stay or move up. That is a slower way to buy a server, but it is the only way I have found that does not end with either a sluggish box or an overpriced one sitting idle.