Amikor a gyorsítótár rossz irányba skálázódik
A szolgáltatás gyorsítótár-mappájában négy kis fájl van. A legnagyobb 35 bájtos. Együtt három számlálószámot tartalmaznak, és minden egyes számlálókérésnél beolvassák őket.
Azért vannak, hogy a számlálási útvonalnak ne kelljen négy olyan kérdést feltennie az adatbázisnak, amelyekre szinte mindig „nem” a válasz. Kizárja-e ez a számláló a tulajdonosa saját látogatásait? Követi-e a kimenő kattintásokat? Követi-e az útvonalakat a weboldalon belül? Újratölti-e magát? A számlálók több mint 99%-ánál minden válasz nem, és egy fájl, amely azt a néhány számot tartalmazza, ahol a válasz igen, olcsóbban lekérdezhető, mint négy indexelt lekérdezés.
Olcsóbb is. De abból a fajta olcsóságból, amely visszájára fordul.
Mit mértünk
Ugyanazt a kérdést — „benne van-e ez a számláló a listában?” — kétféleképpen tettük fel, hat különböző listaméretnél. A fájlos módszer: beolvasás, a JSON dekódolása, a szám megkeresése. Az adatbázisos módszer: egyetlen előkészített utasítás egy indexelt oszlopra. Mindkettőből kétezer ismétlés, öt kör, a medián számít.
A mai méretnél a fájl nyolcszor gyorsabb: 0,0202 ezredmásodperc, szemben a 0,1630 ezredmásodperccel. Ezer számnál egyformák. Tízezernél a fájl tizenkétszer többe kerül, százezernél pedig 135-ször többe, mert addigra 578 kilobájtról van szó, amelyet minden egyes megtekintésnél be kell olvasni és fel kell dolgozni.
Az adatbázis vonala nem mozdul. 0,16 ezredmásodperc két sornál és 0,16 ezredmásodperc százezernél: erre való az index, és könnyű elfelejteni, mennyi munka rejlik amögött, hogy ez a vonal ilyen unalmasan fest.
A kényelmetlen rész
A metszéspont valahol 100 és 1 000 szám között van. Ennek a szolgáltatásnak 2 218 számlálója volt aktív az elmúlt harminc napban.
Ha tehát a kizárási funkció sikeres lenne — ha mindenki, akinek számlálója van, bekapcsolná a „ne számolja a saját látogatásaimat” beállítást —, a fájl 2 218 számot tartalmazna, 11 kilobájtot nyomna, és megtekintésenként 0,02 helyett 0,43 ezredmásodpercbe kerülne. A tegnapi 18 423 megtekintésnél ez napi nyolc másodpercnyi munka, hogy elkerüljünk egy lekérdezést, amely összesen három másodpercig tartott volna.
Az optimalizálás akkor a leggyorsabb, amikor a funkciót a legkevésbé használják. Nem a terheléssel romlik fokozatosan, ahogy egy lassú lekérdezés. Az elterjedéssel romlik, és ez az az egyetlen tengely, amelyet senki sem figyel, hiszen a növekvő használat elvileg a jó hír.
Miért van még mindig itt
Mert ma helyes, és a „ma helyes” lehet valaminek az oka, feltéve, hogy valaki leírta, mikor szűnik meg igaznak lenni.
Három szám három fájlban. Nyolcszor olcsóbb az alternatívánál, egy olyan gépen, ahol egyedül a számlálási útvonalnak kell gyorsnak lennie. Ha most lecserélnénk arra a lekérdezésre, amelyet legyőz, egy feltételezéssel igazolt, rosszabb rendszert kapnánk.
Nem átírásra van szüksége, hanem vészjelzőre. A fájlt amúgy is az adatbázisból írja ki az a kód, amely egy beállítást módosít — ez a természetes hely annak észrevételére és jelzésére, hogy a lista túlnőtt néhány száz bejegyzésen. Egy dokumentált felső határral rendelkező gyorsítótár döntés. Egy felső határ nélküli gyorsítótár fogadás, amelybe senki sem egyezett bele.
Az általános minta
Ez nem érv a fájlban tárolt gyorsítótár ellen. Amellett érv, hogy tudni kell, merre skálázódik egy gyorsítótár.
A legtöbb gyorsítótár terhelés alatt jobb lesz: több kérés, több találat, jobb arány. Ez a másik fajta. Kérésenkénti költsége attól függ, mennyi adatot tartalmaz, és amit tartalmaz, az azzal együtt nő, amit a szolgáltatás ösztönözni próbál. Minden olvasás minden bejegyzésért fizet, beleértve azt a 2 215-öt is, amelynek semmi köze az éppen számolt látogatóhoz.
Bármely memóriában vagy fájlban tartott keresőtábláról nem azt kell kérdezni, hogy „milyen gyors”, hanem azt, hogy „mitől nő, és mi történik, ha az a dolog jól megy”. Ha a válasz az, hogy „lassabb lesz”, akkor a méretkorlát a kódba tartozik, ahhoz a részhez, amely a fájlt írja, már azon a napon, amikor elkészül.