rick/LEDMatrix
1
0
Fork 0
mirror of https://github.com/ChuckBuilds/LEDMatrix.git synced 2026-10-05 23:05:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(espn): fetch a window's edge months whole, cap chunk requests per process

Browse Source 
A soccer board with eight leagues logged ~90 NameResolutionErrors for
site.api.espn.com within a minute of every start on ledpi, plus
"update() timed out". ESPN rejects date ranges, so every league's
fortnight-either-side window became 29 day requests, several managers
fetched it at once, and each window got its own six chunk threads:
~450 requests per start with ~45 in flight, each request past a
session's pool a new connection and a new DNS lookup.

- fetch_espn_date_chunks() asks for a partial edge month whole once the
  window covers ESPN_MONTH_COVER_MIN_DAYS (7) of its days, and trims the
  answer to the window by each event's US Eastern start date, the day
  ESPN's dates=YYYYMMDD means (417/417 live soccer events matched). A
  29-day window over two months is 2 requests, not 29. A live poll's
  1-2 days stay day requests. A capped trimmed month re-asks only the
  window's days; an undatable event is kept. New espn_request_chunks().
- Chunk requests share one process-wide cap of ESPN_CHUNK_WORKERS in
  flight instead of six per window.
- A new process starts as if a range had just been rejected, so it no
  longer spends a doomed 400 per window at every start.

Live ESPN, soccer-scoreboard 2.39.2, alternating runs: ~450 -> 46
requests per start, peak ~45 -> 13 in flight, ~75 -> 30 DNS lookups.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Chuck
2026-10-03 22:35:09 -04:00
co-authored by Claude Opus 5.5
parent 41192b9588
commit 8da7fc01d7
5 changed files with 384 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+23
View File
@@ -19,6 +19,29 @@ accepts both, but the store flags the old spelling as deprecated
## Unreleased
### ESPN date-range fetches: fewer requests, fewer at once
A soccer board (8 leagues, ESPN rejecting `dates=` ranges) logged ~90
`NameResolutionError` lines and an `update() timed out` at every start on a
Pi: each league's fortnight-either-side window was 29 day requests, fetched
by several managers at once, ~40 in flight. Measured against live ESPN with
soccer-scoreboard 2.39.2, alternating runs: **~450 requests per start, peak
~45 in flight, ~75 DNS lookups -> 46 requests, peak 13, ~30 lookups**.
- `fetch_espn_date_chunks()` asks for a window's partial edge month whole
when the window covers `ESPN_MONTH_COVER_MIN_DAYS` (7) or more of its days,
and trims the answer to the window's days by each event's US Eastern start
date -- the day ESPN's `dates=YYYYMMDD` means (417 of 417 live soccer
events matched). A 29-day window spanning two months is 2 requests instead
of 29. Short windows (a live poll's 1-2 days) stay day by day. A trimmed
month that comes back at the 500-event cap re-asks only the window's days.
An event with no readable date is kept. New: `espn_request_chunks()`.
- Chunk requests share one process-wide cap of `ESPN_CHUNK_WORKERS` (6) in
flight, across every window being fetched, instead of six per window.
- A new process starts as if a range had just been rejected, so it no longer
spends one doomed 400 per window at every start (eleven at once from a
soccer board); the range is still retried `RANGE_RETRY_SECONDS` in.
### Cheap per-frame and per-fetch savings
- `BaseOddsManager.get_odds()` no longer pretty-prints every odds response