Matchblatt-Lauf: TTVP-Statistik nur für neue Begegnungen laden #162

Open
opened 2026-10-31 09:18:47 +00:00 by claude · 0 comments
Collaborator

Anlass: Ein Druck auf „Postfach jetzt prüfen“ (Matchblatt-Prüfseite) dauert rund 2 Minuten, auch wenn kein neuer Bogen da ist. Olli wunderte sich am 31.10. darüber.

Gemessen am 31.10. auf der Devbox:

Teil Dauer
Postfach holen (60 Bogen-Anhänge, 75 MB, nur lesend) 9,7 s
TTVP-Statistik scrape-ttvp-results.py --season-id 7 1 min 29 s (Rechenzeit 0,7 s, der Rest ist Warten)

Der Abgleich holt das Postfach danach ein zweites Mal (weitere rund 10 s).

Ursache: scrape-ttvp-results.py lädt bei jedem Lauf die ganze Saison neu: Spielerliste, Wettbewerbe, Events und die Detailseite jeder gespielten Begegnung (heute 75). Vor jeder Seite wartet es 0,5 s (scrape-ttvp-results.py:111), absichtlich, um TTVP zu schonen. Mit jeder Runde kommen Detailseiten dazu. Gegen Saisonende (rund 150 Begegnungen) wären es etwa 3 Minuten; das ist eine Hochrechnung, keine Messung.

Vorschlag: Detailseiten nur für Begegnungen laden, die im Ergebnisverzeichnis noch nicht stehen. Die vorhandenen Partien aus games.csv übernehmen. Ein Lauf ohne neue Spiele läge dann bei etwa 20 s.

Zu klären: Wie fängt man nachträgliche Korrekturen bei TTVP ab? Möglich wären ein gelegentlicher Volllauf (z. B. nachts) oder ein Schalter dafür.

Nicht dazu: Mails in einen Archivordner verschieben. Am 31.10. verworfen: Es spart nichts Messbares (das Postfach braucht 10 s, schon gelesene Bögen kosten dank Zwischenspeicher nichts), „Kein Bogen“ würde falsch, und das Skript bräuchte Schreibzugriff aufs Postfach.

Gilt für den Matchblatt-Dienst auf der Staging-VM (Branch feature/matchblatt-staging). Der Lauf startet den Abruf über scripts/matchblatt-export.py:331.

**Anlass:** Ein Druck auf „Postfach jetzt prüfen“ (Matchblatt-Prüfseite) dauert rund 2 Minuten, auch wenn kein neuer Bogen da ist. Olli wunderte sich am 31.10. darüber. **Gemessen am 31.10. auf der Devbox:** | Teil | Dauer | |---|---| | Postfach holen (60 Bogen-Anhänge, 75 MB, nur lesend) | 9,7 s | | TTVP-Statistik `scrape-ttvp-results.py --season-id 7` | 1 min 29 s (Rechenzeit 0,7 s, der Rest ist Warten) | Der Abgleich holt das Postfach danach ein zweites Mal (weitere rund 10 s). **Ursache:** `scrape-ttvp-results.py` lädt bei jedem Lauf die ganze Saison neu: Spielerliste, Wettbewerbe, Events und die Detailseite **jeder** gespielten Begegnung (heute 75). Vor jeder Seite wartet es 0,5 s (`scrape-ttvp-results.py:111`), absichtlich, um TTVP zu schonen. Mit jeder Runde kommen Detailseiten dazu. Gegen Saisonende (rund 150 Begegnungen) wären es etwa 3 Minuten; das ist eine Hochrechnung, keine Messung. **Vorschlag:** Detailseiten nur für Begegnungen laden, die im Ergebnisverzeichnis noch nicht stehen. Die vorhandenen Partien aus `games.csv` übernehmen. Ein Lauf ohne neue Spiele läge dann bei etwa 20 s. **Zu klären:** Wie fängt man nachträgliche Korrekturen bei TTVP ab? Möglich wären ein gelegentlicher Volllauf (z. B. nachts) oder ein Schalter dafür. **Nicht dazu:** Mails in einen Archivordner verschieben. Am 31.10. verworfen: Es spart nichts Messbares (das Postfach braucht 10 s, schon gelesene Bögen kosten dank Zwischenspeicher nichts), „Kein Bogen“ würde falsch, und das Skript bräuchte Schreibzugriff aufs Postfach. Gilt für den Matchblatt-Dienst auf der Staging-VM (Branch `feature/matchblatt-staging`). Der Lauf startet den Abruf über `scripts/matchblatt-export.py:331`.
Sign in to join this conversation.
No description provided.