diff options
| author | eunhhu <[email protected]> | 2026-09-27 08:09:40 +0100 |
|---|---|---|
| committer | eunhhu <[email protected]> | 2026-09-27 08:09:40 +0100 |
| commit | 5d3a7cefa27f3fe20a9c6991fb044815b38aac01 (patch) | |
| tree | b6e06c7976eddd846430cd809f7ace5e80553449 /research/experiments/002-buffer-retention/benchmark.c | |
| parent | 01c87d2c204723905457f225b3113dac82eb0ced (diff) | |
| download | pure-5d3a7cefa27f3fe20a9c6991fb044815b38aac01.tar.gz pure-5d3a7cefa27f3fe20a9c6991fb044815b38aac01.zip | |
Deliver an app's saved sends over HTTP, in order and in batches (083)
pure-serve --send OUTPUT=http://host:port/path wires an output: after
every save the owner queues the new sends as JSON (fields and groups)
and a thread per output posts them in order with X-Pure-Source,
X-Pure-Sequence and Idempotency-Key. A 2xx, or a Pure receiver's
refusal, delivers; the owner then trims. 408, 429, 5xx and no answer
are sent again after a pause growing to 10 s, other answers every 10 s:
nothing is dropped. A Pure receiver applies a delivered message with
pure_app_deliver (now taking placed fields) and advertises
X-Pure-Batch: 256; the sender then posts up to that many numbers in a
row as one JSON array (X-Pure-Count), applied in order in one burst
with one save.
Delivery kept up with orders once batched (391 deliveries/s one at a
time; a backlog of 20,000 went at 60k/s). With four clients ordering,
killing the receiver and then the sender (-9) left the receiver's count
and total equal to what the sender saved, five times and under ASan.
Diffstat (limited to 'research/experiments/002-buffer-retention/benchmark.c')
0 files changed, 0 insertions, 0 deletions
