Site resources: PHP threads, memory, and CPU

Every site runs in its own isolated container on an Avaloi server. Your plan sets how much work the container can do at once. This page explains the numbers you see on a site's Info tab.

PHP threads

A PHP thread handles one uncached request at a time. Pages served from the cache do not use a thread, so most visits never reach PHP. Threads matter for logged-in users, carts and checkouts, the admin area, and pages that are not cached yet.

Plan	PHP threads	PHP memory pool	Memory the site may use
Starter	4	1 GB	up to 4 GB
Pro	6	1.5 GB	up to 6 GB
Business 1	8	2 GB	up to 8 GB
Business 2	12	3 GB	up to 8 GB
Business 3	16	4 GB	up to 8 GB
Agency	16	4 GB	up to 8 GB
Enterprise 1	24	6 GB	up to 8 GB

Each thread gets 256 MB of memory for a request, so the pool is the threads times 256 MB. A PHP memory add-on raises the pool. Plan cards and the pricing page do not list thread counts.

When all threads are busy, new uncached requests wait in line. If your site often waits, a larger plan or caching more pages helps more than anything else.

Memory the site may use

The memory limit in the last column is a ceiling, not a reservation. Most sites use a small part of it: a quiet site runs in well under 1 GB, and the PHP pool is only what the threads may use if they are all busy at once. Avaloi counts what your site really uses, not the ceiling, when it decides how many sites share a server, and it keeps the server well under full so a busy moment has room.

If a burst takes your site past about four fifths of its limit, the server slows the site's memory use down before anything stops. At the limit itself a process can be stopped, and the site starts it again. The server does not swap your site's memory to disk, because a slow disk would slow every site on the server.

Database and other memory

Your site's database gets its own buffer on top of the PHP pool: 384 MB on Starter, up to 2 GB on Enterprise 1, and at least 128 MB on any plan. The buffer fills only as the database is read, so a small database uses a small part of it. The container also keeps memory for its PHP code cache, the web server, and SSH.

CPU

A live site has no fixed CPU limit. It can use every core of its server when they are free. When several sites are busy at once, each gets a share in line with its plan (a heavier share on a bigger plan), so a busy neighbor cannot take your share. A site can run up to 1,000 processes on Starter and Pro, and more on larger plans.

Your live site is always served first

When the server is busy, your live site goes ahead of every staging, multidev, and preview environment, including your own. A live site on the smallest plan gets 15 times the CPU share of a staging environment and 5 times the share of a premium staging environment. A bigger plan gets a bigger share still. Disk access follows the same order, so a staging copy that reads or writes a lot cannot starve your live site's disk.

This order only matters while the server is busy. When the server has spare capacity, nothing is held back except the one core limit that staging always has. So a load test on staging or a multidev environment slows that environment down first, and your live site keeps its speed.

If a server stays busy for a minute or more, Avaloi stops putting new sites on it and starts or uses another server. Sites already there keep running.

Staging

Staging and multidev environments use a single CPU core and 2 PHP threads. Premium staging gets half of live's PHP threads and also uses one core. That keeps staging cheap; it is not meant for load tests. When the server is busy, staging and multidev get a small share of the CPU, and premium staging gets three times that, so live is always served first.

Page cache

Pages for visitors who are not logged in are cached on the server. The cache skips logged-in users, carts and checkouts, the admin area, login, and form posts, so those always see fresh content. Avaloi clears the cache when you publish or update content.