Wanneer een cache de verkeerde kant op schaalt
In de cachemap van deze dienst staan vier kleine bestanden. Het grootste is 35 bytes. Samen bevatten ze drie tellernummers, en ze worden bij elke telleraanvraag gelezen.
Ze bestaan zodat het telpad de database niet vier vragen hoeft te stellen die hij vrijwel altijd met "nee" beantwoordt. Sluit deze teller de eigen bezoeken van zijn eigenaar uit? Volgt hij uitgaande kliks? Volgt hij paden door de site? Herlaadt hij zichzelf? Bij meer dan 99% van de tellers is elk antwoord nee, en een bestand met het handjevol nummers waar het antwoord ja is, is goedkoper te raadplegen dan vier geïndexeerde bevragingen.
Het is goedkoper. Het is ook het soort goedkoop dat omslaat.
Wat er gemeten is
Dezelfde vraag — "staat deze teller in de lijst?" — op twee manieren gesteld, bij zes lijstgroottes. De bestandsmanier: lees hem, ontleed de JSON, zoek het nummer. De databasemanier: één voorbereide opdracht tegen een geïndexeerde kolom. Elk tweeduizend herhalingen, vijf rondes, mediaan genomen.
Bij de omvang van vandaag wint het bestand met een factor acht: 0,0202 milliseconde tegen 0,1630. Bij duizend nummers zijn ze gelijk. Bij tienduizend kost het bestand twaalf keer meer, en bij honderdduizend kost het 135 keer meer, want dan zijn het 578 kilobytes die bij elke treffer gelezen en ontleed moeten worden.
De databaselijn beweegt niet. 0,16 milliseconde bij twee regels en 0,16 milliseconde bij honderdduizend: daar is een index voor, en het is makkelijk te vergeten hoeveel werk er schuilgaat achter hoe saai die lijn eruitziet.
Het ongemakkelijke deel
Het omslagpunt ligt ergens tussen de 100 en de 1.000 nummers. Deze dienst heeft 2.218 tellers die in de laatste dertig dagen actief waren.
Was de uitsluitingsvoorziening een succes — zette iedereen met een teller "tel mijn eigen bezoeken niet mee" aan — dan zou het bestand 2.218 nummers bevatten, 11 kilobytes wegen, en 0,43 milliseconde per treffer kosten in plaats van 0,02. Bij de 18.423 treffers van gisteren is dat acht seconden werk per dag om een bevraging te vermijden die er drie gekost zou hebben.
De optimalisatie is het snelst wanneer de voorziening het minst gebruikt wordt. Ze verslechtert niet geleidelijk onder belasting, zoals een trage bevraging doet. Ze verslechtert met het gebruik, en dat is de ene as waar niemand naar kijkt, want meer gebruik hoort juist het goede nieuws te zijn.
Waarom hij er nog staat
Omdat hij vandaag klopt, en "vandaag klopt" mag de reden voor iets zijn, zolang iemand heeft opgeschreven wanneer dat ophoudt waar te zijn.
Drie nummers in drie bestanden. Acht keer goedkoper dan het alternatief, op een machine waar het telpad het enige is dat snel moet zijn. Hem nu vervangen door de bevraging die hij verslaat, zou een slechter systeem zijn dat met een hypothese verantwoord wordt.
Wat hij nodig heeft, is de struikeldraad, niet de herbouw. Het bestand wordt toch al vanuit de database geschreven, door de code die een instelling wijzigt — dat is de natuurlijke plaats om op te merken dat de lijst voorbij een paar honderd vermeldingen is gegroeid en dat te zeggen. Een cache met een opgeschreven plafond is een besluit. Een cache zonder plafond is een gok waarmee niemand heeft ingestemd.
De algemene vorm
Dit is geen argument tegen cachen in een bestand. Het is een argument om te weten welke kant een cache op schaalt.
De meeste caches worden beter onder belasting: meer aanvragen, meer treffers, betere verhouding. Deze is van de andere soort. Zijn kosten per aanvraag zijn een functie van hoeveel gegevens hij bevat, en wat hij bevat groeit mee met het ding dat de dienst probeert aan te moedigen. Elke leesbeurt betaalt voor elke vermelding, ook voor de 2.215 die niets te maken hebben met de bezoeker die nu geteld wordt.
De vraag die je bij elke opzoektabel in geheugen of in een bestand moet stellen, is niet "hoe snel is hij" maar "waardoor groeit hij, en wat gebeurt er wanneer dat goed gaat". Is het antwoord "hij wordt trager", dan hoort de omvangsgrens in de code, naast het ding dat het bestand schrijft, op de dag dat hij gebouwd wordt.