Sizing
elements man deploy/sizingWhat an app is, the two deploy tiers, the two sizes, and how to pick them from the number of customers and visitors.
What Counts as One App
One database is one app. Everything that shares customers, logins, orders, sessions or files is the same app, however many domains it answers on. A personal site, a brand's site and that brand's community are one app when the same people log in to all three: sessions and authentication are per app, and one database is what gives those people one login across every host.
Admin screens and internal tools are routes in the same app behind an admin role. A separate app is for something with its own users and its own data.
One app serves many hosts. deploy.domain takes a list and every host goes
into the certificate; the load balancer routes by host, and a route can be
restricted to one with domain:. See Load Balancer (opens in a new tab) and
elements man router.
The Two Tiers
| Prototype | Production | |
|---|---|---|
| App | one machine | one machine |
| Database | the bundled Postgres on that machine | a managed Postgres at the provider |
| Backups | none | daily, kept seven days, by the provider |
| Second machine | needs the move below | a deploy |
Prototype is the cheapest thing that is a real server with the app's own address. Nothing to provision beyond the box: the first deploy installs Postgres on it. Production starts the database on the provider's managed Postgres from day one, so backups, restores and a second app machine are there when they are wanted, with no migration in the way. The move from one to the other is a recipe in Operations (opens in a new tab).
Pick production for anything with customers in it.
The Two Sizes
| Small | Large | |
|---|---|---|
| App machine | 1 GB RAM, 20 GB disk | 4 GB RAM, 40 GB disk |
| Database (production) | the provider's smallest Postgres, 1 GB RAM, 20 GB storage | the same, with a standby and automatic failover |
| Who | one project, a content or business site | several projects on one box, batch work, a business that loses money in an hour of downtime |
Start with small. Each side moves to the next size on its own, as a class change with a few minutes of downtime and no data move.
Memory is what sizes the app machine, not CPU. The project server, the app, the load balancer and (on a prototype) Postgres share the box's RAM, which is why 1 GB holds one project and 4 GB holds several. The database is sized by whether its data fits in its RAM: queries run from memory until it does not.
From Customers and Visitors to a Size
An agent asked "I have a few thousand customers and so many visitors a month, what do I need?" answers from these rules.
- Visitors a month, V. Page views are about 3V. Requests, counting the HTML, the RPC calls and the images a browser has not cached, are about 4 per page view. The browser caches every asset after its first visit, so a repeat visit fetches HTML and data only.
- The busiest second of the month runs at about V divided by 30,000 requests per second. 50,000 visitors a month is 1 to 2 requests a second at peak.
- Concurrent users are daily active users times minutes per session, divided by active hours times 60. A few thousand customers are a few at a time, and a few dozen on the day a newsletter goes out.
- A customer with orders, comments and a profile is 10 to 50 KB. A page view row is about 200 bytes, so a million a year is a few hundred MB.
| Visitors a month | App machine | Database |
|---|---|---|
| up to about 300,000 | small | small |
| up to about 1,000,000, or several projects, or batch work | large | small, large when an hour of downtime costs money |
| beyond | a second machine | large |
At every row of that table the machine is mostly idle. A few thousand customers with ad traffic to funnels, newsletter sends and uploads are at a few percent of the small machine, and their data fits in the small database's RAM for years.
Crawlers
On a content site the robots outnumber the people. Search engines, AI
crawlers and SEO tools fetch pages on their own schedule, and they fetch HTML,
not assets. They are most of the requests on a quiet day and still a rounding
error on the bill. A robots.txt and a block on the scrapers you do not want
are the whole of the tuning.
When to Grow
- App machine to large: the deploy reports an out-of-memory diagnostic, or a second project is going on the box, or the app does batch work like image processing or large sends.
- A second app machine: the site has to survive a machine dying. Not for capacity until a large machine is pegged at peak, which is rare before the database is.
- Database to the next class: its data no longer fits in its RAM, or the provider's metrics show it short of CPU credits or connections.
- Database to a standby: an hour of restore time would cost real money.
The order is a bigger machine, then a second machine, then a bigger database.
What Goes on the Database Server
One instance, on the smallest class the provider offers. Elements creates the app and test databases on it at the first build. No read replicas, no connection proxy, no second database for the test suite. A standby for failover is the only addition, and only on the large tier.