Performance, measured
We loaded a RespireCloud installation on five rented servers on 19 October 2026 and wrote down what happened, including what went wrong. These are the real numbers, with the hardware and the method. They are one afternoon's run, not a promise about your sites.
The headline numbers.
At 1000 concurrent visitors, from three generators, on a 4 vCPU server with 8 GB of memory.
- 10.8krequests a second, static site, 95th percentile 93 ms, no errors
- 7.6krequests a second, Node.js app, 95th percentile 153 ms, no errors
- 4.6krequests a second through Kubernetes on two small servers, no errors
- 4 of 65,095requests lost when a web server was stopped under load
Every target we measured.
The 95th percentile of a fast page is about 93 ms because the network round trip from the generators was about 91 ms. The server's own part is the difference.
Rows are at 1000 concurrent visitors unless the notes say otherwise. The panel's own API is not in the table: it limits each token on purpose.
Updates and failures.
What happened to traffic while something changed or broke.
-
Updating the panel while sites are served
The panel was updated from 1.0.2 to 1.0.3 through the product in about 40 seconds, while a static site and a PHP site were probed once a second for 22 seconds. None of those probes failed. The panel's own health check failed on 5 of the 22 probes, about 8 seconds, while its service restarted. The four other servers followed to the new version by themselves within minutes. A small sample: it shows the design works, not that it is perfect.
-
A web server stops under load
With the static pool running at 100 connections for 60 seconds, one of the two web servers was stopped for 25 seconds. 65,091 requests were answered and 4 failed (0.006%). The load balancer took the stopped server out at once, and put it back by itself when it started again, with no failed request.
-
A Kubernetes node is lost
When one of two k3s nodes was stopped, its pods were moved to the other after about 5 minutes, which is Kubernetes's default patience. During that time 310 of 583 probes of the ingress failed. That is a real gap, and it is filed as a bug.
Hardware and method.
-
Date and version
19 October 2026, RespireCloud 1.0.3 (version 1.0.2 plus two fixes made during the test). A first run of version 1.0.0 the same day is the baseline.
-
The servers
Five rented cloud servers at Hetzner: the main one with 4 vCPU and 8 GB of memory (panel, web server, MariaDB and Docker together), a second web server and a load balancer with 2 vCPU each, and two small servers with 2 vCPU each running k3s.
-
The load
Three generators at OVH, 4 vCPU each, running oha 1.16.0 for 30 seconds per step at 50, 200, 500 and 1000 concurrent visitors, split evenly between them. The round trip from the generators to the servers was about 91 ms, so the 95th percentile of a fast page cannot be below about 91 ms.
-
What counts as an error
Anything that is not an HTTP 2xx answer, timeouts included. The requests per second are the sum of the three generators; the latency is that of the slowest generator.
-
What it is not
One run of one afternoon on rented servers, with sites made for the test and no cache in front of them. It shows where the limits are, not what your sites will do.
Where it was weak.
We list these because you would find them yourself.
-
PHP and WordPress are the slow part
Dynamic sites are limited by their worker pool and, for the WordPress container, by a half CPU quota. Both are settings, not the server's ceiling, and a page cache was not part of this test.
-
PHP behind the load balancer failed under saturation
At 500 and 1000 visitors, 71% and 87% of requests to the PHP pool through the load balancer got a 503. The balancer's health check timed out while the site was saturated, and the second server had been marked down because its database copy was read only. At 200 visitors there were no errors. This is filed as a bug.
-
The first run found a real fault, now fixed
In the first run (1.0.0) the PHP site answered 87% of requests at 1000 visitors with a misleading 404, because the web server ran out of open files. The limit was raised in version 1.0.3, and the same load then produced no errors.
-
The API is rate limited on purpose
A single token may make about 10 to 30 calls a second. Above that the panel answers 429, and answering a flood still costs a 4 vCPU server most of its CPU.
Questions
- How many requests a second can a RespireCloud server serve?
- On a 4 vCPU cloud server in our test, about 10,800 requests a second of a static site and about 7,600 of a Node.js app at 1000 concurrent visitors, with no failed requests. A PHP page that writes to a database served about 300 a second, and a WordPress container about 7. The method and the limits are on this page.
- Were any customer requests lost during an update?
- In the test, a static site and a PHP site were probed once a second for 22 seconds while the panel updated itself, and none of those probes failed. The panel's own health check failed for about 8 seconds while its service restarted.
- What happens when a web server in a pool fails?
- With 100 connections running for 60 seconds, one of two web servers was stopped for 25 seconds: 65,091 requests were answered and 4 failed. The load balancer removed it at once and added it back by itself.
Want your own numbers?
Ask for early access and run your sites on a server of your own. The install guide lists the sizes.