Scaling applications
This page is for application creators whose application must serve more users or more data. Scale in steps, measuring before each one: most sites never need more than the first three.
Contents
Measure first
php bin/php/console exp:benchmark --save=var/benchmark/base.json --allow-root-user
php bin/php/console exp:benchmark kernel --repeat=30 --allow-root-userexp:benchmark gives median, p90 and p99 per page; kernel mode times boot, render, INI load, fetches and database
round trips (Benchmarking, Profiling and performance).
The steps, in order
| Step | Effect | Read |
|---|---|---|
| 1. Caches on and keyed right | most requests never render | Caching in applications |
| 2. Velocity with its response cache | anonymous repeat requests answered without PHP; persistent workers keep the application warm | Velocity response cache |
| 3. Slow work out of requests | requests stay fast under load | Background work |
| 4. The database tuned; query cache | fewer and cheaper queries | Databases, SQL query cache |
| 5. Search on Solr | search load off the database | Search with ezfind and Solr |
| 6. Shared cache backend | content and INI caches in Redis or Valkey | sevenx_valkey_cache |
| 7. Several web servers | horizontal capacity | Clustering and shared storage |
Velocity's worker pool and its dynamic sizing are set in velocity.ini
(8.3.6 Workers).
Several web servers
Multiple web servers need: one database (or a cluster of it), shared file storage through the cluster file handler,
the same code and settings on every server, sessions every server can read (the database session handler), a load
balancer listed in TrustedProxies[], and cron and queue workers on one designated server (or locked).
Application design that scales
- Every list paged and limited; counts with count queries.
- No per-request work proportional to the size of the site (whole-tree fetches in the pagelayout).
- Writes batched, transactions short.
- Idempotent background jobs, so more workers do not mean duplicates.
- Caches keyed by what changes, cleared by events rather than by time where possible.
Related pages
- Performance and caching for websites
- Clustering and shared storage
- 10.12 Performance tuning
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.