Skip to content
AquadactylAquadactyl
Wings

Wings vs Manta benchmarks

Fresh local measurements of stock Wings and the current Manta build, including API, file operations and memory use.

Measured 2026-10-15. This is a local comparison of stock Wings v1.13.4 and the recorded Manta working-tree build, with identical daemon CPU/memory limits. The homepage shows three fixed metrics; the tables here include the other measured workloads, including regressions.

Homepage comparison · Full raw results · Runner source · Manta source patch

Compared builds

SettingWingsManta
SourceOfficial v1.13.4 releaseBase commit 747bc4393daf plus linked local patch
Go compilergo1.27.2go1.27.2
CPU quota2 cores2 cores
Memory limit1024 MiB1024 MiB
GOMAXPROCS22

Both image IDs and daemon binary SHA-256 values are recorded in the raw report. Wings uses the official image with only a BusyBox probe added; its executable is unchanged. Manta was rebuilt from the local checkout before this run. Both executables use the same recorded Go compiler version. Source and dependency differences are part of the tested distributions; this does not isolate any one code optimization.

The dedicated benchmark nodes each manage one Paper and one Bedrock server with matching game images, binary hashes, resource limits, seed and startup settings. Existing unrelated user servers are excluded from the requests. These are existing benchmark worlds: the first start in this rerun is a cached restart, not first world creation. No player bots or authenticated players participated.

API throughput and latency

Three repetitions alternate daemon order. Each endpoint/concurrency combination sends 400 authenticated HTTP requests using persistent connections at concurrency 1, 16 or 32. The client runs inside Docker on the shared local network, with a 4-core quota and 1 GiB memory limit. These short closed-loop batches report observed throughput, not sustained production capacity. Panel and daemon benchmark workloads ran separately.

Throughput is the median of three batch rates. The p50/p95 columns are medians of three per-batch percentiles, not pooled percentiles. Lower latency and higher throughput are preferable. 14,400 timed API requests completed with 0 errors.

MeasurementWingsManta
Server status, concurrency 1: throughput4484.064 req/s4578.652 req/s
Server status, concurrency 1: p500.211 ms0.207 ms
Server status, concurrency 1: p950.334 ms0.323 ms
Server status, concurrency 16: throughput43154.424 req/s47467.237 req/s
Server status, concurrency 16: p500.267 ms0.220 ms
Server status, concurrency 16: p950.962 ms0.796 ms
Server status, concurrency 32: throughput41278.669 req/s43011.779 req/s
Server status, concurrency 32: p500.549 ms0.556 ms
Server status, concurrency 32: p952.237 ms1.809 ms
List 1,000 files, concurrency 1: throughput103.943 req/s136.715 req/s
List 1,000 files, concurrency 1: p509.508 ms7.170 ms
List 1,000 files, concurrency 1: p9511.114 ms8.701 ms
List 1,000 files, concurrency 16: throughput171.630 req/s258.292 req/s
List 1,000 files, concurrency 16: p5085.567 ms52.822 ms
List 1,000 files, concurrency 16: p95185.602 ms138.296 ms
List 1,000 files, concurrency 32: throughput166.103 req/s244.205 req/s
List 1,000 files, concurrency 32: p50158.793 ms109.397 ms
List 1,000 files, concurrency 32: p95430.931 ms282.363 ms

Startup and shutdown

Three measured warm start/stop repetitions per game and daemon, after the first start of the run is discarded. Timers run from the power API request until the daemon reports running/offline, polled every 100 ms. Shutdown is the reported state transition, not a separately measured OS process exit.

MeasurementWingsManta
paper: warm startup9599.269 ms9593.543 ms
paper: reported offline909.477 ms909.374 ms
bedrock: warm startup2224.734 ms2222.375 ms
bedrock: reported offline1010.306 ms1212.726 ms

File and event operations

Three repetitions; transfers use five samples per repetition and a shared random 16 MiB payload. Read-back integrity checks happen outside transfer timers. SFTP authentication is outside the transfer timer and uses the same local Panel for both daemons. Archive round trips verify restored content. Rows show the median of per-run measurements.

MeasurementWingsManta
HTTP write 16 MiB14.209 ms13.272 ms
HTTP read 16 MiB28.634 ms11.899 ms
SFTP write 16 MiB118.960 ms125.839 ms
SFTP read 16 MiB58.016 ms64.345 ms
Chmod 1,000 files6.241 ms4.506 ms
Rename 1,000 files16.319 ms16.346 ms
Compress 16 MiB + 1,000 files18.510 ms20.832 ms
Extract archive63.254 ms62.369 ms
Deliver 100 log lines to 16 subscribers9.862 ms9.246 ms

Memory use

One approximately 30-second idle window and one approximately 30-second command-load window, with 15 Docker working-set samples per container per window. Values are arithmetic means of those samples, not medians or process RSS. Working set is container usage minus inactive file cache; the raw result retains sampled peaks and CPU observations. Daemon memory excludes its game containers, Panel, database, Redis and host overhead. No forced garbage collection occurs between workloads.

The command workload alternates a 4,096-block area between stone and air at five commands per second per game, using matching forced/ticking areas. Java/Bedrock status queries occur while the workload remains active; these are not player latency measurements.

MeasurementWingsManta
daemon: idle working memory62.426 MiB61.434 MiB
paper: idle working memory725.924 MiB732.339 MiB
bedrock: idle working memory185.958 MiB186.090 MiB
daemon: command_load working memory50.368 MiB51.460 MiB
paper: command_load working memory747.072 MiB750.017 MiB
bedrock: command_load working memory253.394 MiB253.734 MiB

Compatibility checks

These checks report the harness's expected behavior and are separate from performance. A different result is not an overall security assessment. Exact statuses/events are in the raw report.

CheckWingsManta
unauthenticated_apiPassPass
oversized_json_knownDifferent behavior (see raw result)Pass
oversized_json_chunkedDifferent behavior (see raw result)Pass
multiple_json_documentsDifferent behavior (see raw result)Pass
valid_websocket_tokenPassPass
future_issued_tokenDifferent behavior (see raw result)Pass
future_not_before_tokenDifferent behavior (see raw result)Pass
expired_tokenPassPass
missing_expiry_tokenPassPass
raw_stream_above_json_limitPassPass
one_time_file_tokenPassPass
invalid_upload_token_log_redactionDifferent behavior (see raw result)Pass
ssrf_loopback_blockedPassPass
sftp_symlink_containmentPassPass
full_uuid_sftpDifferent behavior (see raw result)Pass
modern_identifier_sftpDifferent behavior (see raw result)Pass

Reproduce and limits

Host: Intel(R) Core(TM) i7-14700KF; 64 GiB RAM; win32 10.0.26300 x64. Shared Windows/WSL2 Docker workstation, existing unrelated containers running, no CPU pinning, WAN/TLS emulation, real players or endurance load. Results depend on configuration, workload and the short observation windows. They cannot establish a universal speed-up or an overall performance score.

Use the exact source/image/binary hashes in the raw report. The linked Manta patch and measured runner source record the local changes. The existing dedicated stack and cached game installations were provisioned with the Manta repository's benchmarks/provision.php; its README documents the local node setup and manifest guards. It is not a fresh-machine deployment recipe. The full run starts/stops only those four benchmark servers and writes fixtures under their bench directories.

From the Manta checkout, with the dedicated stack prepared and matching CPU/memory overrides applied:

.\benchmarks\Run-Benchmark.ps1 -Phases lifecycle,performance,resources,security -OutputDirectory C:\path\to\fresh-results

Keep the private manifest out of published artifacts. The runner creates a temporary credential file and removes it after the run. Publish only the credential-free JSON outputs, source hashes and runner snapshot. From the website checkout, rebuild the homepage data after both comparisons finish with node scripts/write-comparison-showcase.mjs.