RPC

Payload Sizes

How every server behaves as the request body grows.

The heavy validation route on every server, at four payload sizes from about 1 KB to 4 MB. It shows what happens when a request no longer fits in one network read.

Each size also runs the same mion server with compact JSON, which sends objects without their key names. Percentages are against plain JSON.

How it is tested

~1 KB

$ loading benchmark…

JSON vs compact JSON:

$ loading benchmark…
$ loading benchmark…

~50 KB

$ loading benchmark…

JSON vs compact JSON:

$ loading benchmark…
$ loading benchmark…

~500 KB

$ loading benchmark…

JSON vs compact JSON:

$ loading benchmark…
$ loading benchmark…

~4 MB

$ loading benchmark…

JSON vs compact JSON:

$ loading benchmark…
$ loading benchmark…

Test Setup

Each request is the updateUser call from heavy validation, padded to the target size by repeating its payment methods. Each one is a member of a discriminated union in the model, so every server validates the whole body at every size. All the hello world servers run here, so the sizes compare frameworks, not just mion's own adapters.

mion.compact is the mion server with parser: 'compact' on the router. Bytes count the request and response bodies of one call, without headers.

Why these sizes? A body over 512 KB cannot arrive in one socket read, and the uWebSockets adapter takes a different, copy-free path for it. The 500 KB case is the last one that fits in a single read, the 4 MB case does not.
Fewer connections on the largest payload. Every size has the same cap on request-body bytes in flight, so bigger payloads mean fewer requests at once. Without it, 4 MB bodies would mostly wait in a queue, and the run would measure the queue instead of the server.
Copyright © 2026