Browser, API and memory benchmarks

Measured 2026-10-15. These runtime tests extend the separate frontend build and asset comparison. All values below come from running panels and a real headless browser.

Homepage comparison · Raw samples · Summary · Measured runner source

This historical report retains its original revisions and measurements. See the current panel comparison for newer results and the archived build record for the frontend artifacts used in this run.

Scope and compared versionsCopy Anchor Link

One non-admin user owning 50 suspended server records, one node, one nest, one egg, one allocation per server. No Wings calls or running game containers in the measured stacks.

PHP 8.5, four static FPM workers, OPcache 128 MiB, PHP memory_limit 256 MiB; nginx one worker with gzip level 6; config/route/view caches; one queue worker. Each panel 2 CPU quota cores/1 GiB; each MariaDB 1 core/512 MiB; each Redis 0.5 core/128 MiB. REDIS_CLIENT=phpredis on both. Production mode, debug and telemetry off, no extra addons.

Both applications use their own locked production Composer dependencies and freshly built production frontend artifacts. No application source was patched. Configuration, caches and fixture data were created only in disposable containers. The common runtime base was built from Aquadactyl's Dockerfile; both panels run from a separate /bench directory with their own vendor trees and the identical benchmark web-server configuration. The inherited /app tree is not served or loaded.

These controlled settings differ from default deployments: PHP-FPM is fixed at four workers, both panels use the native Redis driver, and API throttles are raised equally. Results compare these tested distributions and settings; they do not isolate a single code change or framework version.

Browser load timeCopy Anchor Link

Headless Chromium, 1440x900, deviceScaleFactor 1, no CPU or network throttling, localhost Docker port forwarding. One warm-up pair discarded; ten measured pairs per panel in alternating order. Cold uses a new context restored from an authenticated session; warm reloads the same page/context. Server/OS caches remain warm. Wait for all 50 server names, then 2 seconds to observe paints. Third-party requests are blocked identically to isolate the local panel; blocked URLs are recorded. FCP/LCP are navigation-to-paint; dashboardReady is measured when all server names exist in DOM, a custom application milestone. Heap is CDP JSHeapUsedSize after an explicit garbage collection; not total browser RAM.

Cold means cold browser HTTP cache, with a pre-existing authenticated session. It does not mean a cold PHP process, database or OS cache. Warm is the next full-page reload in that context, with HTTP caching available. This measures the dashboard, not login or a client-side route transition. Login is outside all timings.

The dashboard-ready milestone uses animation-frame polling until all 50 fixture server names exist in the DOM, so it includes data fetching and rendering but has roughly one-frame observation granularity. It is not a standardized Time to Interactive or a field Core Web Vitals result. LCP is the latest candidate observed during the two-second settling window, not an unlimited observation of later page activity.

Each distribution renders its own dashboard layout and normal response fields. LCP candidates can therefore be different elements, and these tests compare the whole shipped page rather than an identical UI rewritten with two libraries.

There are ten measured samples per panel/cache profile; with this small sample, p95 is the maximum sample. Each panel had one discarded cold/warm pair. No real users or physical mobile devices were measured.

External resource URLs blocked during the measured loads: none were requested.

Resources transferred by the browserCopy Anchor Link

This sums Resource Timing transferSize values observed by the end of each settling window, including fonts, styles, scripts and API responses, and excluding the main HTML navigation. Warm cache hits can report zero transfer bytes. These browser observations have a wider scope than the build benchmark's JavaScript/CSS-only gzip estimate. Aquadactyl's smaller script/style bundle does not imply less total page transfer or faster dashboard readiness.

The timing APIs follow Navigation Timing, Paint Timing and Largest Contentful Paint. Browser collection uses Playwright CDP sessions.

Authenticated API throughputCopy Anchor Link

GET /api/client/account and GET /api/client?per_page=50, valid user API key, HTTP/1.1 persistent connections, uncompressed response bodies, concurrency 1/8/16; 10-second closed-loop windows, three repetitions with alternating panel order. Two-second warm-up before each run. No new requests after the window, in-flight requests drained and included in elapsed time. Validate every HTTP status and JSON result. Rate limits raised to 1,000,000/min on both disposable panels. Successes per actual elapsed second, not offered requests per second or a maximum capacity claim.

The account endpoint returns the fixture user's account; servers returns all 50 owned server records, including the panel's own server transformers and relationships. The server-list responses contain each distribution's normal fields, so response sizes differ. Neither endpoint contacts Wings. Results are endpoint-specific and do not describe file transfers, server power operations or every panel API.

Throughput is the median of three measured windows. Each p95 below is the median of the three per-window p95 values, not a percentile pooled across all requests. The raw report includes every successful request latency and all run durations, status counts and load-generator event-loop delays.

Across the 36 measured API windows: 36,116 successful responses, 0 errors. Warm-up and memory-load requests are additional and excluded from these totals. The default 256 requests/minute limiter was not being measured; raising its configured cap leaves the normal authentication, authorization and rate-limit middleware active.

Memory useCopy Anchor Link

cgroup v2 memory.current minus inactive_file, clamped to zero (Docker-style working set). Separately retain raw usage bytes. Ten 1-second-spaced samples per window, three windows each after warm-up, idle and during concurrency-16 server-list load. Each sample records panel, database and Redis, and their sum. Peak is the maximum observed sample, not the kernel high-water mark. No application restarts or forced PHP GC between windows. Browser heap and server working set are different metrics.

The panel container includes nginx, supervisor, the FPM master and its four PHP workers, plus one queue worker. The stack column additionally includes that panel's separate MariaDB and Redis containers. It excludes Docker Desktop/WSL overhead, the load generator, browser and unrelated game containers. Library and OPcache pages shared among workers are accounted at container level, rather than adding process RSS values and double-counting shared pages.

Each state has 30 samples per panel across three windows. Loaded samples use the authenticated 50-server-list endpoint at concurrency 16. The Docker working-set calculation follows Docker's documented cache subtraction. These are short steady-state observations, not a leak or long-running capacity test.

Sampling pauses one second between collections; container-exec overhead adds to that interval. The raw report retains each sample timestamp. The helper shell and Docker sampling overhead are present for both panels.

Browser JavaScript heapCopy Anchor Link

This is the median CDP JSHeapUsedSize after explicit garbage collection from the same ten dashboard samples. It excludes DOM/native allocations, images, GPU memory and browser processes; it must not be described as total browser memory.

Environment and limitsCopy Anchor Link

Single shared Windows/WSL2 workstation; existing unrelated game containers remain running. No CPU pinning, controlled network emulation, TLS, WAN latency, mobile device, endurance test or real-player load. This is a controlled local configuration comparison of pinned distributions, not their default deployment presets or proof of general production capacity.

Browser observations, API windows and memory windows ran in separate phases. Panels were tested sequentially within each phase, alternating which panel ran first by repetition. The measured panel stacks do not run game servers; existing unrelated containers were left untouched. Changing CPU quotas, PHP worker counts, dataset, caching, browser, network or optional features can change the outcome. Differences should be read per metric, without combining them into an overall performance score.

ReproduceCopy Anchor Link

Check out the exact source commits above. Use clean source checkouts. Install each panel's locked dependencies and run its production frontend build (Aquadactyl: pnpm build; Pterodactyl: yarn build:production) before preparing the stacks. The historical build comparison describes asset collection separately. Build Aquadactyl's runtime image first (the test reuses its PHP extensions and OS packages for both panels), then run these commands from the website repository:

docker build -t aquadactyl:test /path/to/aquadactyl-bench
pnpm exec playwright install chromium
node scripts/prepare-runtime-benchmark.mjs /path/to/aquadactyl-bench /path/to/pterodactyl-bench

The preparation script prints a temporary directory. Replace WORKDIR below with that path:

docker compose -f WORKDIR/compose.json up -d --build --wait --wait-timeout 240
node scripts/benchmark-runtime.mjs WORKDIR public/benchmarks/runtime.json
node scripts/write-runtime-benchmark-guide.mjs runtime
node scripts/verify-runtime-benchmark.mjs runtime
docker compose -f WORKDIR/compose.json down --volumes

The generated Compose file binds only to 127.0.0.1:8091 and :8092 and has its own network, volumes and random disposable credentials. Never point this harness at a production database. The raw public report omits credentials and sessions. Keep its Composer lock hashes, image IDs and individual samples with any published comparison. The headline chart imports only the smaller summary, not the per-request latency arrays.