De opzoeking vermenigvuldigde zichzelf #84

Merged

roelof merged 1 commit from opzoeken-niet-vermenigvuldigen into main

2026-08-06 20:18:47 +02:00

roelof commented

2026-08-06 20:16:41 +02:00

Owner

Herstelt de traagheid die je live ziet: een ronde die minutenlang op één track blijft staan. Hij loopt wél door — maar zó langzaam dat het niet zo lijkt.

De rekensom

Een track die niets oplevert kostte na #73:

3 artiestspellingen  ×  3 titelverkortingen  ×  2 zoekopdrachten  =  18 verzoeken

Bij één verzoek per seconde is dat twintig seconden per track, en zodra MusicBrainz begint te weigeren — wat in je log te zien is — lopen de wachttijden met verdubbelingen op tot minuten. Dat is mijn eigen verandering uit #73, die die twee reeksen op elkaar stapelde.

Waarom dat fout was

Ze beantwoorden verschillende vragen. Een naam die MusicBrainz niet kent wordt niet beter van het inkorten van de songtitel, en een titel die te lang is wordt niet beter van een andere spelling van de band. Ze horen dus achter elkaar en niet door elkaar:

de titelverkortingen tegen de artiest zoals de tag hem geeft
dan de overige spellingen tegen de titel zoals die staat

Vijf opzoekingen in plaats van negen. En alleen de eerste doet de strikte zoekopdracht erbij — die bestaat om de honderd plaatsen aan platen te besteden voor de vraag zoals hij gesteld is, en hem opnieuw stellen over een titel die al ingekort is levert niets op voor de seconde die het kost.

ten hoogste 6 verzoeken, waar het er 18 waren

Meten

Aan de klok is het slecht te meten — MusicBrainz throttlet de ene minuut wel en de andere niet, en dezelfde vier tracks gaven bij herhaling wisselende tijden. Metallica's The Unforgiven I, dat niets oplevert, ging van 8,3 s naar 1,1 s. Het harde getal is het aantal verzoeken, en dat volgt uit de code.

Wat te doen met de lopende ronde

Ik zou hem stoppen (POST /api/jobs/cancel), dit mergen en opnieuw draaien. Wat af is blijft af — een track met een release-group id op zijn albumrij wordt niet opnieuw bevraagd — dus je verliest niets en de rest gaat ruwweg drie keer zo snel.

Herstelt de traagheid die je live ziet: een ronde die minutenlang op één track blijft staan. Hij loopt wél door — maar zó langzaam dat het niet zo lijkt. ## De rekensom Een track die niets oplevert kostte na #73: ``` 3 artiestspellingen × 3 titelverkortingen × 2 zoekopdrachten = 18 verzoeken ``` Bij één verzoek per seconde is dat twintig seconden per track, en zodra MusicBrainz begint te weigeren — wat in je log te zien is — lopen de wachttijden met verdubbelingen op tot minuten. Dat is mijn eigen verandering uit #73, die die twee reeksen op elkaar stapelde. ## Waarom dat fout was Ze beantwoorden **verschillende vragen**. Een naam die MusicBrainz niet kent wordt niet beter van het inkorten van de songtitel, en een titel die te lang is wordt niet beter van een andere spelling van de band. Ze horen dus achter elkaar en niet door elkaar: 1. de titelverkortingen tegen de artiest zoals de tag hem geeft 2. dan de overige spellingen tegen de titel zoals die staat Vijf opzoekingen in plaats van negen. En **alleen de eerste doet de strikte zoekopdracht erbij** — die bestaat om de honderd plaatsen aan platen te besteden voor de vraag zoals hij gesteld is, en hem opnieuw stellen over een titel die al ingekort is levert niets op voor de seconde die het kost. ``` ten hoogste 6 verzoeken, waar het er 18 waren ``` ## Meten Aan de klok is het slecht te meten — MusicBrainz throttlet de ene minuut wel en de andere niet, en dezelfde vier tracks gaven bij herhaling wisselende tijden. Metallica's *The Unforgiven I*, dat niets oplevert, ging van **8,3 s naar 1,1 s**. Het harde getal is het aantal verzoeken, en dat volgt uit de code. ## Wat te doen met de lopende ronde Ik zou hem stoppen (`POST /api/jobs/cancel`), dit mergen en opnieuw draaien. Wat af is blijft af — een track met een release-group id op zijn albumrij wordt niet opnieuw bevraagd — dus je verliest niets en de rest gaat ruwweg drie keer zo snel.

roelof added 1 commit

2026-08-06 20:16:41 +02:00

De opzoeking vermenigvuldigde zichzelf 29d7712604

Een lopende scan bleef minutenlang op één track staan. Hij liep wel door, maar
een track die niets oplevert kostte achttien MusicBrainz-verzoeken: drie
artiestspellingen maal drie titelverkortingen maal twee zoekopdrachten. Bij één
verzoek per seconde is dat twintig seconden, en zodra MusicBrainz begint te
weigeren lopen de wachttijden op tot minuten. Dat is mijn eigen verandering uit
#73, die die twee reeksen op elkaar stapelde.

Ze beantwoorden verschillende vragen. Een naam die MusicBrainz niet kent wordt
niet beter van het inkorten van de songtitel, en een titel die te lang is wordt
niet beter van een andere spelling van de band. Ze horen dus achter elkaar en
niet door elkaar: eerst de titelverkortingen tegen de artiest zoals de tag hem
geeft, dan de overige spellingen tegen de titel zoals die staat. Vijf
opzoekingen in plaats van negen.

En alleen de eerste opzoeking doet de strikte zoekopdracht erbij. Die bestaat om
de honderd plaatsen aan platen te besteden voor de vraag zoals hij gesteld is;
hem opnieuw stellen over een titel die al ingekort is levert niets op voor de
seconde die het kost. Daarmee komt het slechtste geval op zes verzoeken in
plaats van achttien.

Wat het oplevert is aan de klok slecht te meten — MusicBrainz throttlet de ene
minuut wel en de andere niet — maar Metallica's The Unforgiven I, dat niets
oplevert, ging van 8,3 s naar 1,1 s. Het harde getal is het aantal verzoeken, en
dat volgt uit de code: ten hoogste zes waar het er achttien waren.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

roelof merged commit 4a5d093ce3 into main

2026-08-06 20:18:47 +02:00

roelof deleted branch opzoeken-niet-vermenigvuldigen

2026-08-06 20:18:47 +02:00

roelof referenced this pull request from a commit

2026-08-06 20:18:48 +02:00

Merge pull request 'De opzoeking vermenigvuldigde zichzelf' (#84) from opzoeken-niet-vermenigvuldigen into main