# How to scale a PHP application

Source: https://www.fortrabbit.com/how-to-scale-a-php-application
Published: 2026-10-13
Reviewed: 2026-10-13

> A PHP application scales by faster responses, background jobs, more PHP processes and, last, more instances. With a requests-per-second table.


A PHP application scales in two directions: more PHP processes on one instance, or more instances behind a load balancer. Start with the processes. One PHP-FPM process answers one request at a time, so capacity is the number of processes divided by the average response time. Four processes at 250 ms serve 16 requests per second, the same four at one second serve 4. A faster response is therefore the cheapest scaling step, and it comes before any hardware. Second, move slow work such as mail, image transforms, and imports into background jobs, so the web processes stay free for visitors. Third, book more processes and more memory. More instances come last, because they need an app without local state: sessions, uploads, and caches have to live outside the instance. On fortrabbit an environment runs on one instance and scales vertically, so the first three steps are the ones on offer.

## Requests per second by processes and response time

| Response time | 2 processes | 4 processes | 8 processes | 12 processes |
| ------------- | ----------: | ----------: | ----------: | -----------: |
| 100 ms        |          20 |          40 |          80 |          120 |
| 250 ms        |           8 |          16 |          32 |           48 |
| 500 ms        |           4 |           8 |          16 |           24 |
| 1 s           |           2 |           4 |           8 |           12 |

These are upper limits. Every request is assumed to take the average. A page view is often more than one PHP request, because an AJAX call or an image transform takes a process of its own. A request that arrives while all processes are busy waits in line. Aim for 250 ms or less on average.

## Scaling up with more PHP processes

On fortrabbit, [managed PHP cloud hosting](/php-cloud-hosting), the PHP component sets memory and process count together:

| Plan | Memory | PHP processes | Per month |
| :--- | ---: | ---: | ---: |
| XS | 128 MiB | 2 | €1 |
| SM | 256 MiB | 2 | €2 |
| MD | 512 MiB | 4 | €4 |
| LG | 1 GiB | 6 | €12 |
| XL | 2 GiB | 8 | €25 |
| 2XL | 4 GiB | 12 | €50 |

The plan is booked per environment, so staging stays small while production grows. PHP does not autoscale: processing time differs too much between apps to pick one threshold. The memory of a plan is shared by all its processes, and a request that loads too much gets a process killed. The docs [performance section](https://docs.fortrabbit.com/dev/performance) covers how to find such requests.

## Background jobs

Sending mail, resizing images, and importing feeds do not belong in a web request. The [jobs component](https://docs.fortrabbit.com/platform/components/jobs) runs queue workers and cron jobs in a separate container with access to the same files and database.

## The database

The [MySQL component](https://docs.fortrabbit.com/platform/components/mysql) scales separately, though it usually grows in step with PHP. Each PHP plan comes with matching MySQL connections, one per process and a few for clients from outside. A slow query holds a PHP process for as long as it runs, so read the slow queries before booking a larger plan.

## Scaling out with more instances

Horizontal scaling puts the same app on several instances behind a load balancer. The price is an app that keeps nothing on local disk: sessions in a shared store, uploads in object storage, a deploy that reaches every instance.

We dropped it on purpose. On our previous platform a small share of apps needed it, and the horizontally scaled stack was not much more available in practice than the single-instance one. [On horizontal scaling](https://blog.fortrabbit.com/on-horizontal-scaling) has the long version. An app that has outgrown the largest PHP component belongs on a hyperscaler, with someone hired to run it.

## FAQ

### How many PHP processes does an application need?

**Peak × response time** — Multiply the PHP requests per second at peak by the average response time in seconds. At 20 requests per second and 250 ms, five processes are busy. Add headroom for the slow requests.

### Does PHP autoscale on fortrabbit?

**No** — MySQL, storage, and traffic autoscale. The PHP component is booked at a fixed size and changed by hand in the dashboard, per environment.

### Does fortrabbit offer horizontal scaling?

**No** — An environment runs on one instance. The PHP component scales vertically, up to the largest PHP plan.

---

- [Performance](/dev/performance)
- [PHP processes](/dev/performance/php-processes)
- [PHP component](/platform/components/php)
- [Jobs component](/platform/components/jobs)
- [PHP cloud hosting](/php-cloud-hosting)