# Testing the new platform's performance

Source: https://blog.fortrabbit.com/hosting-performance-testing
Published: 2026-10-01
Author: Erin Strand
Tags: chronicles

> Load-testing the new fortrabbit hosting platform.


## A bet on network storage

Our new hosting platform makes a bold choice: files no longer live on the web server's own disk, but on network storage. This is slower by definition. Did that bet cost us speed? We spent some weeks finding out.

Unlike most 'modern' cloud hosting platforms, we offer direct SSH access and a persistent file system: fortrabbit is serverful hosting. The old platform keeps files on the server's local disk. It has served us well for more than a decade — a credit to our two technical co-founders Ulrich and Oliver — and it is fast by design, but it ties apps to their servers. Moving the files off the web server lets us perform maintenance, deployments and config changes with zero app downtime. It is one of the reasons why we rebuilt the platform — see [yes, we rewrite](/yes-we-rewrite).

## Putting it to a realistic test

Now that the new platform serves real traffic every day, we can test it properly. Craft CMS, Kirby, Statamic and Laravel are our bread and butter. Their installers come without real content, the custom content makes the music. So a few clients graciously allowed us to clone and anonymize their apps, and we built a [k6](https://k6.io/) test suite around two of them, a classic and a headless Craft CMS site, plus the Kirby demokit.

Every test runs against three contenders: the **old platform**, the **new platform**, and a **$12 VPS** we set up ourselves with the same apps.

## Assumptions and improvements

Several weeks of testing put some of our assumptions to the test, and we tweaked and readjusted many things along the way. Here are the main findings:

### The network file system is not the bottleneck

We expected to pay for network storage in exchange for flexibility. Our tests proved: swapping it for faster disk storage made no difference to how quickly a single visitor gets a page. It only shows under very heavy traffic, and only when other very busy apps share the same server or other special cases.

### CPU core limits

On the old platform, all apps have full access to the full CPU power of the node it runs on. This is to allow apps to briefly burst when they need it. This can be a traffic burst or resizing an image, or some other CPU intensive task. If this gets out of hand and one or even a few apps start hogging the CPU, this can affect other apps.

To completely avoid this CPU competition issue on our new platform, we started out with a strict 1 core max burst limit for all apps. During testing we discovered that the new platform was performing worse than the old, and a big part of it came down to this CPU limit.

So we mostly removed that limit again (for now). Apps now share a node's CPU more freely, so a very busy neighbor can slow others down for a moment. We are keeping an eye on this, and if this turns out to be a problem we have several ways to mitigate it with our new tooling. The good news here is that apps can now burst twice as much for CPU intensive tasks, speeding up those previously slower tasks.

### Older CPUs cost more

With the new platform beta, we started out small. Since we did not yet have as many apps as the old platform, we used smaller nodes than the old platform did. This turned out to also have a serious impact on performance. These smaller nodes often used older generation CPUs, heavily impacting pure CPU performance.

We have now moved to only using newer CPUs, similar in speed to what the old platform runs on. This lifted performance yet again in our performance tests.

### The first pageview after a deploy

We also discovered that early beta testers complained about their apps being slow after every deployment. This happens because when new code is deployed, we restart PHP-FPM to force it to read new config and code, but this also empties the opcache which caches all code files in memory. Meaning the first request is much slower than normal, as it has to rebuild those caches.

We have now introduced an automated cache filling request, that happens after every deployment, before the first real end user request comes in. So deployments should no longer slow down real visitors. Another performance improvement.

## Results

All figures below were measured after these changes. A word on scale first: in our experience, nobody notices a page that answers in under 250 ms. Complaints start somewhere between half a second and a second. And the stress test below pushes apps far beyond everyday traffic, on purpose.

### Latency test — a single visitor

One request at a time. Median time to first byte, 3 rounds of 25 requests per page:

| App                          |    VPS |    OLD |    NEW |
| ---------------------------- | -----: | -----: | -----: |
| Kirby demokit — PHP pages    |  22 ms |  28 ms |  44 ms |
| Craft classic — PHP pages    | 151 ms | 100 ms | 132 ms |
| Craft headless — GraphQL API |  91 ms |  57 ms |  99 ms |

_Median_ is the middle of the sorted times: half the requests were faster, half slower. Unlike an average, one slow outlier can't drag it up.

The VPS wins on Kirby, helped by sitting about 8 ms closer to our test machine. On Craft it falls behind both platforms: the VPS single shared core is weak at the kind of work a big framework does.

The new platform still trails the old one by a few dozen milliseconds per page — all well inside those 300 ms, and we keep working on it.

### Arrival test — stress test

This test fires requests at a fixed rate of page views per hour, the way real visitors arrive to a very popular site. One minute per level, p95 response time:

| PV/h    | Kirby OLD | Kirby NEW | Craft headless OLD | Craft headless NEW |
| ------- | --------: | --------: | -----------------: | -----------------: |
| 4,000   |     58 ms |     79 ms |              87 ms |             217 ms |
| 40,000  |     61 ms |     90 ms |             211 ms |              1.5 s |
| 80,000  |     60 ms |    113 ms |              2.0 s |  9.3 s, 51% errors |
| 100,000 |     60 ms |    110 ms |             422 ms |            stopped |

_p95_ is the time 95% of requests came in under; only 1 in 20 was slower. Under load that slow tail grows first, so it shows trouble before the median does.

Kirby is where the new platform shines. Our Kirby app ran on the smallest PHP plan, XS, rated for ~200 page views per hour. It took 100,000 page views per hour without a single error, and 95% of pages still came back in under 115 ms.

Mind the scale: our  is rated ~4,000 PV/h, the first level here. The Craft app ran on MD, rated ~1,000 PV/h. With the Craft app, old platform holds 40,000 PV/h, and the new one starts to queue at that level and fails at 80,000 — about one step behind. The old platform's 80,000 row caught a short hiccup; it recovered at 100,000. A gap, but far past any traffic these sites will ever see.

### A note on VPS comparison

Sometimes people compare a small fortrabbit app — around $5 a month, everything included — with a $5 VPS, run some quick tests and conclude the VPS is faster and thus the better option. So we tested against a VPS at more than twice that price: a $12 DigitalOcean droplet. On the flat-file Kirby demo it answered faster. On the Craft apps the new platform kept pace: ahead on one, within 8 ms on the other.

Cheap VPS prices are also under pressure: hardware costs across the industry are rising, and the days of the super cheap VPS might be ending. Hetzner have [recently increased all prices](https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/), their cheapest VPS is now €5.99 on ARM or €11.49 on AMD64, plus €0.50 for an IPv4 address.

## Closing words

We will keep measuring and tuning performance throughout the BETA. This post is a snapshot, not the finish line. We are evaluating to include CPU share with the plans in the future.

Next up on our roadmap are a key-value store, performance metrics and a CDN integration. And when your app is slow, we help you find out why: the  covers the common fixes, and personal support covers the rest.

In contrast, a VPS is only the server. Updates, security patches, backups, deployments and weekend on-call are yours to handle. With fortrabbit they're ours — that's our product: the dashboard, the tooling and the time it saves you, with performance on par with any VPS in the same price range.