När en cache skalar åt fel håll

Fyra små filer ligger i den här tjänstens cachemapp. Den största är 35 byte. Tillsammans innehåller de tre räknarnummer, och de läses vid varenda räknarförfrågan.

De finns för att räknevägen inte ska behöva ställa fyra frågor till databasen som den nästan alltid besvarar med ”nej”. Utesluter den här räknaren ägarens egna besök? Spårar den utgående klick? Spårar den vägar genom webbplatsen? Laddar den om sig själv? För mer än 99 % av räknarna är varje svar nej, och en fil med den handfull nummer där svaret är ja är billigare att slå upp i än fyra indexerade frågor.

Den är billigare. Men det är en sorts billighet som kan vända.

Vad som mättes

Samma fråga — ”finns den här räknaren i listan?” — ställd på två sätt, vid sex liststorlekar. Filvägen: läs filen, avkoda JSON-datan, leta efter numret. Databasvägen: en förberedd sats mot en indexerad kolumn. Tvåtusen upprepningar vardera, fem omgångar, medianvärdet.

Vid dagens storlek vinner filen med en faktor åtta: 0,0202 millisekunder mot 0,1630. Vid tusen nummer är de jämna. Vid tiotusen kostar filen tolv gånger mer, och vid hundratusen kostar den 135 gånger mer, eftersom den då är 578 kilobyte som måste läsas och tolkas vid varje visning.

Databaslinjen rör sig inte. 0,16 millisekunder vid två rader och 0,16 millisekunder vid hundratusen: det är vad ett index är till för, och det är lätt att glömma hur mycket arbete som döljer sig bakom hur tråkig den linjen ser ut.

Den obekväma delen

Brytpunkten ligger någonstans mellan 100 och 1 000 nummer. Den här tjänsten har 2 218 räknare som har varit aktiva de senaste trettio dagarna.

Så om uteslutningsfunktionen blev en succé — om alla som har en räknare slog på ”räkna inte mina egna besök” — skulle filen innehålla 2 218 nummer, väga 11 kilobyte och kosta 0,43 millisekunder per visning i stället för 0,02. Med gårdagens 18 423 visningar blir det åtta sekunders arbete per dag för att slippa en fråga som hade tagit tre.

Optimeringen är snabbast när funktionen används minst. Den försämras inte gradvis med belastningen, som en långsam fråga gör. Den försämras med spridningen, den enda axel som ingen bevakar, eftersom att fler använder funktionen ska vara de goda nyheterna.

Varför den finns kvar

För att den är rätt i dag, och ”rätt i dag” får vara skälet till något, så länge någon har skrivit ner när det slutar vara sant.

Tre nummer i tre filer. Åtta gånger billigare än alternativet, på en maskin där räknevägen är det enda som måste vara snabbt. Att nu ersätta den med frågan som den slår vore ett sämre system, motiverat av ett hypotetiskt scenario.

Det den behöver är en snubbeltråd, inte en omskrivning. Filen skrivs ändå utifrån databasen, av koden som ändrar en inställning — det är det naturliga stället att märka att listan har vuxit förbi några hundra poster och säga ifrån. En cache med ett dokumenterat tak är ett beslut. En cache utan tak är ett vad som ingen har gått med på.

Det allmänna mönstret

Det här är inget argument mot att cacha i en fil. Det är ett argument för att veta åt vilket håll en cache skalar.

De flesta cacher blir bättre under belastning: fler förfrågningar, fler träffar, bättre träffkvot. Den här är av det andra slaget. Dess kostnad per förfrågan beror på hur mycket data den innehåller, och det den innehåller växer med just det som tjänsten försöker uppmuntra. Varje läsning betalar för varje post, inklusive de 2 215 som inte har något att göra med besökaren som räknas just nu.

Frågan att ställa om varje uppslagstabell i minnet eller i en fil är inte ”hur snabb är den” utan ”vad får den att växa, och vad händer när det går bra”. Om svaret är ”den blir långsammare” hör storleksgränsen hemma i koden, bredvid det som skriver filen, samma dag som den byggs.