Graham McIntire
b6b5945002
CommonVolumeRadarWorker was enqueuing one job per contact — every job fetched + decoded the ~5 MB n0q PNG for its own 5-min frame. At current backlog depth that's 17,588 contacts across just 1,747 distinct 5-min frames, i.e. ~10 contacts per frame paying for the same PNG decode over and over. New RadarFrameWorker takes a batch of contact_ids sharing one frame, fetches + decodes the frame ONCE, then walks the in-memory pixel buffer per contact. build_radar_jobs/1 in ContactWeatherEnqueueWorker now groups the input contacts by their rounded 5-min timestamp and emits one RadarFrameWorker job per frame instead of one CommonVolumeRadarWorker per contact. process_frame/4 is public so the same code path is used both by perform/1 (production fetch) and tests (pre-decoded pixel buffer); keeps the happy-path test hermetic without hand-crafting a PNG. CommonVolumeRadarWorker stays in the tree — still used from the single-contact submit path where batching is pointless and the aggregate_stats/5 pure helper is a dependency of the new batched worker. Expected impact on the backfill: ~10x fewer fetch + decode cycles, so the 17k queued-contact backlog drains in minutes instead of ~50. |
||
|---|---|---|
| .. | ||
| microwaveprop | ||
| microwaveprop_web | ||
| mix/tasks | ||
| microwaveprop.ex | ||
| microwaveprop_web.ex | ||