Sizing a 50-site network against per-account resource limits

Sizing a network against per account limits is arithmetic, not guesswork. The inputs are how many dynamic requests each site really generates, how many of those survive caching, and how much headroom you want on a bad day. Everything else follows from those three numbers.

Start with requests, not visits

Monthly visits are the wrong unit because limits are instantaneous. Convert to concurrency instead.

Take a site with 30,000 visits a month. That is roughly 1,000 a day, and traffic is never flat, so assume half of it lands in a busy six hour window. That is about 500 visits over 21,600 seconds, or one visit every 43 seconds. Even at three page views per visit, this site is nowhere near a concurrency constraint. Multiply it by fifty sites and it is still modest.

The lesson generalises: for content sites, ordinary traffic almost never exhausts an account. What exhausts an account is a few slow requests holding slots, or work happening with no traffic at all.

Then subtract what caching removes

Server level caching serves a stored copy without executing the application. On a content network that typically removes the large majority of dynamic requests, and it is the single biggest variable in this calculation. A cached site and an uncached site with identical traffic have completely different resource profiles.

So size the network with caching assumed, then verify it is actually working rather than assuming it. An uncached front page is the most common reason a well sized plan feels undersized. See Speed and Caching for confirming it is on.

Group sites so their peaks do not collide

Since the ceiling is per account, grouping is the real design decision. Three rules that hold up:

• Separate the spiky from the steady. One shop or one busy blog next to twenty brochure sites will set the pace for all of them.
• Separate by schedule. Sites that publish, import or back up at the same time compete at that time. Stagger the schedule or split the account.
• Separate by platform requirement. Sites in one account share one PHP version, so one legacy site pins the group.

A worked layout

Say fifty sites: forty small content sites, eight moderate, two busy.

1. The two busy ones: their own accounts. They are the ones that will spike, and you want that contained.
2. The eight moderate ones: split across two or three accounts, grouped so their publishing schedules differ.
3. The forty small ones: comfortable together in a small number of accounts, because their combined dynamic load after caching is genuinely low.

Note that none of this decides how many addresses you need. Grouping is a resource decision; addresses are a footprint decision, and they are independent. Fifty sites need fifty distinct addresses if you want fifty distinct footprints, regardless of how many accounts they sit in. That side is covered in Sizing and Selection.

Leave headroom, then verify

Size for the busy hour with room to spare, not for the average. A plan that runs at 90 percent on a normal day has nothing left for the day something goes wrong, and something always goes wrong: a crawler arrives, a post does unusually well, an update misbehaves.

Then check the fault counters after two weeks of real traffic. Predicted load and observed load differ, and the counters are the only honest referee. If they are clean, you sized correctly. If one account is generating faults, you now know exactly which group to split rather than guessing.

The limit reference is at docs.cloudlinux.com. If the numbers say one workload genuinely needs reserved resources, compare it against a KVM VPS rather than moving the whole network.