Listing latency at one user went from 1.95 ms on the previous release to
3.25 ms on main, and a bisect put the whole of it on the compression commit.
Not on compressing: the harness never sent Accept-Encoding, so nothing was
ever gzipped. Hono's middleware still inspects every compressible response it
declines and sets Vary on it, and setting a header on a streamed passthrough
rebuilds the Response off its fast path -- about 1.2 ms per JMAP call, on a
request that had asked for nothing.
The middleware now runs only when the request names gzip or deflate. Measured
at one user against the same Stalwart:
compressor touches but declines, no Accept-Encoding 3.25 ms
skipped entirely, no Accept-Encoding 2.02 ms
compressor applied, Accept-Encoding: gzip 2.27 ms
previous release, either 1.95 ms
Applying gzip to a JMAP response costs about a quarter of a millisecond and
saves three to five times the bytes on every listing and body, so JMAP
responses stay compressed by default; COMPRESS_JMAP=0 turns that off for a
deployment that would rather not.
The raw push relay is also made safe to tear down from outside -- the
browser stream keeps its headers and is not ended when the upstream request
goes -- which the next change relies on.
jcoffey-dev
f569f2cc7a