Capacity planning #

This page is for IT teams and project managers in public bodies who must specify servers for an Exponential site, often for a procurement or a budget request. It answers which figures the repository actually gives, what drives memory, CPU and disk use, and how to measure your own site so the specification rests on evidence. It gives no figures of its own; the installation book says the same: "The documentation gives few hard numbers, and this book does not invent others" (Sizing memory, CPU and disk).

Contents #

1. The figures the repository gives
2. What drives load
3. Measure your own site
4. Planning for peaks
5. Writing a server specification
6. Checklist

The figures the repository gives #

All from Sizing memory, CPU and disk, which also lists the MongoDB figures and the log rotation limits. Measured figures are from the project's own machines; yours will differ.

What drives load #

• Cached pages cost little. Anonymous visitors are answered by the response cache or the HTTP cache without PHP (Velocity response cache and HTTP cache).
• Rendered pages (first views after a clear, signed-in editors, searches, forms) are where CPU goes.
• PHP processes use up to their memory_limit at peak; imports, package installs and image work need the most.
• Disk grows with uploads in var/storage, which is usually the main factor; caches and logs are bounded by rotation and can be cleared.
• Cron and image variations add bursts.

Measure your own site #

php bin/php/console exp:benchmark --save=var/benchmark/base.json --allow-root-user
php bin/php/console exp:system:info --json --allow-root-user
du -sh var/storage var/cache var/log

exp:benchmark requests the front page, menu pages, the search page and the admin login page and prints median, p90 and p99; it is polite by default (Benchmarking). Measure the same request before and after a change; "a single page load proves nothing" (Deploying). Run it against a test copy with production content, not against the live site at a busy time.

Planning for peaks #

Public-sector sites have predictable peaks (deadlines, election results, school enrollment) and unpredictable ones (storms, emergencies). For both:

• make sure the pages that will be visited are cached and warm (Cache warming after changes);
• avoid full cache clears and deploys right before a known peak;
• know how to raise Velocity's Workers and restart, and measure again after each change;
• consider a lightweight, mostly static information page for emergencies (Static cache).

Writing a server specification #

For a procurement or budget request, write the specification from measurements, and label the rest:

Checklist #

• To do: Production pools have memory_limit 256M or more.
• To do: Velocity's Workers is set explicitly and tested.
• To do: Disk monitoring uses the System information thresholds.
• To do: A benchmark of a test copy is saved as the reference.
• To do: The server specification separates measured figures from assumptions.

Related pages #

• Availability index of this folder
• Velocity workers and pools
• Benchmarking a hosted site
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.