Slow queries in replay endpoints
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- backend-api-design, databases
Direzione di ricerca
Start with Game.java and the referenced V107__baseline_schema.sql indexes, then inspect later migrations in FAForever/db and the query plan for the map-filtered, newest-first /data/game request. Check whether the proposed composite index is appropriate for this query and how Elide uses it. Done means the change is measured against the reported slow search and its impact on other queries is considered.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Searching games by map is slow for popular maps
Searching /data/game with a filter on the map name takes up to 20 seconds when the map is popular. The same search without the sort, or with a player filter added, answers in under 0.2 s. Claude says this may be because of a missing index. This would be a small change, but I can't oversee the exact implications myself. Essentially this is suggested:
A composite index in FAForever/db:
CREATE INDEX game_stats_mapId_startTime ON game_stats (mapId, startTime);
I've always noticed that the replay tab can be quite slow, this has been happening for years. I only make this ticket because I noticed that it may be a small fix. But I don't know how Elide interacts with an additional index. If I am totally off based on your gut, then feel free to close this immediately.
The query
The web vault (https://vault.jipwijnia.nl) searches games like this, 12 per page, newest first:
GET /data/game
?include=playerStats,playerStats.player,mapVersion,mapVersion.map,featuredMod
&sort=-startTime
&page[size]=12&page[number]=7
&page[totals]
&filter=endTime=isnull=false;mapVersion.map.displayName=="*Seton*"
Measurements
Measured on 2026-10-06 from a browser, with a bearer token. The API caches answers per URL (repeating a URL returns in about 55 ms), so each search was run three times with a different page (7, 8 and 9) to make every call uncached. The three runs were within 2% of each other.
Search (all with endTime=isnull=false) |
Matching games | Time |
|---|---|---|
| No other filter | 19.2 million | 1.25 s |
No other filter, no page[totals] |
0.08 s | |
| Player (a player with about 5,000 games) | 5,087 | 0.22 s |
Map *Seton* |
1.35 million | 20.8 s |
Map *Seton*, no page[totals] |
19.1 s | |
Map *Seton*, no page[totals], no include |
19.0 s | |
Map *Seton*, no page[totals], no sort |
0.09 s | |
Map "Seton's Clutch" (exact), no page[totals] |
14.8 s | |
Map *Fields of Isis*, no page[totals] |
4.6 s | |
Map *Theta Passage*, no page[totals] |
1.1 s | |
Player and map *Seton* |
834 | 0.14 s |
The moment I search for a map with many replays + sorting the endpoint time explodes.
Suspected cause
Game maps to game_stats and reaches the map through mapId → map_version → map. In the schema, game_stats has separate indexes on mapId and on startTime (twice: startTime and game_stats_startTime_index), but none on both together. No later migration adds one.
So for "the newest 12 games on this map" the database has to either collect all games of the map's versions through mapId and sort them (1.35 million rows for Seton), or walk all games backwards through startTime and check the map of each. Both fit the timings above: fast without the sort, slower the more the map is played.
- Lingua principale
- Java
- Stelle
- 31
- Fork
- 30
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di FAForever/faf-java-api
-
Replay review requests from the client, via the api and RabbitMQForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
FAForever/faf-java-api#1181 · 12 commenti ·
-
set local yml for tilt stackAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 30/100
FAForever/faf-java-api#895 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
FAForever/faf-java-api#816 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
FAForever/faf-java-api#708 · 13 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
FAForever/faf-java-api#496 · 1 commento ·
Tutte le issue di FAForever/faf-java-api
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
sqlcipher/sqlcipher-android#97 · 1 commento ·
-
bug IIIF interoperability
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Netcracker/qubership-integration-platform#1046 ·
I maintainer di solito rispondono entro 2 giorni
-
`check_java_version()` fails when Java path contains spaces (Windows / Git Bash, `C:\Program Files`)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100