cache
The built-in smart accelerator — a block of the ROOT settings.json, one memory budget shared by every site. It is on by default — a root file without a cache block runs with the defaults below; add the block to tune them or to opt out with enabled: false. The server counts requests per URL; once a public page, API response, static file or media file gets hot (many requests per minute), the ready answer is kept in memory and served without touching the database, the template engine or the disk.
| key | default | description |
|---|---|---|
| enabled | true | set false to turn the accelerator off |
| mem_percent | 20 | share of the machine's free memory the cache may occupy (1–80); free memory is re-measured every second, when it shrinks the cache shrinks too |
| ttl_minutes | 10 | max age of a cached answer; also how fast a file edited on disk behind the server's back is picked up |
| hot_per_minute | 30 | requests per minute to one URL before it counts as hot and gets cached |
| max_entry | 512k | largest single answer to keep, a number or "512k" / "2m"; ceiling 16m — big media files are streamed from disk as usual |
Example — keep it on but be more conservative:
"cache": { "mem_percent": 10, "ttl_minutes": 5 }You never serve stale content. Any change made through the admin (create, edit, delete, media upload) and every cms reload invalidates that site’s cached answers instantly; the popularity counters survive, so a hot page is re-cached on the very next request. Text answers are stored zstd-compressed — browsers that support zstd get them compressed on the wire, others get them unpacked. Answers that have not reached the hotness threshold yet are compressed on the fly for zstd browsers too, so even the very first visitor of a quiet site gets compressed text. Each cached answer carries an ETag, so repeat visitors often receive an empty 304 Not Modified instead of the body.
How to check it works: request a popular page twice-in-a-row past the threshold and look at the response headers — a cache hit carries X-Cache: HIT. For example: curl -sI https://your.site/ | grep -i x-cache.
The admin area (/cms), the SQL endpoint (/soe) and all POST requests are never cached. All keys are hot-reloadable — edit and run cms reload, no restart needed.