Számlálóképek gyorsítótárazása a memóriában
A szolgáltatás által rajzolt számlálóképek közel ötöde már semmit sem változtat. Egy előző generációs egérkövető szkript minden mozdulatnál újratölti a képet, és mivel ezek a kérések már semmit sem növelnek, két egymást követő kérés ugyanazt a képet adja, bájtra pontosan.
Kézenfekvő jelölt a gyorsítótárazásra. Az érdekes döntés az volt, hová tegyük, és mi legyen a kulcsa.
Nem a lemezre
Mindez egy kis szerveren fut, és a lemez egy SD-kártya. Ha oda gyorsítótáraznánk a megrajzolt képeket, az nagyjából ezzel járt volna: napi 70 MB írás, cserébe egy mért napi 1,6 perc processzoridőnyi megtakarításért.
Ez rossz üzlet. Az SD-kártyák az írástól mennek tönkre, amit pedig cserébe kapnánk, az kerekítési hiba egy olyan gépen, amelyet nem a processzor korlátoz. Ezért a gyorsítótár itt van: /dev/shm, ami tmpfs, vagyis RAM. Ott mérve: 0,027 ms az olvasás, 0,036 ms az írás, 1,9 GB szabad.
Újraindításkor minden eltűnik. Egy gyorsítótárnál ez nem veszteség, hanem a normális eset.
A Redis ugyanazon a gépen fut. Nem használtuk, olyan okból, amelynek semmi köze a technológiához: egy másik alkalmazáshoz tartozik, és annak céljára jelszóval védett. Egy közös példány két, egymással össze nem függő szolgáltatást kötne össze, így az egyik rossz napja a másiké is lenne.
A kulcs tartalmazza a számokat
A szokásos gyorsítótárkulcs egy azonosító plusz egy lejárat, és a lejárat egy fogadás: az elmúlt öt percben semmi fontos nem változott. Egy számlálónál viszont pontosan az változik, ami a képen látható.
Ezért a megjelenített értékek bekerülnek a kulcsba. Ha egy szám megváltozik, az már egy másik kulcs, és a kép újonnan rajzolódik ki. A fogadás eltűnik, ahelyett hogy óvatosan megkötnénk. Minden számolt látogatás legalább a teljes összesített számot növeli, így egyetlen számolt látogatás sem kaphat elavult képet. A megmaradó lejárat csak felső korlát azokra az értékekre, amelyek nincsenek a kulcsban — a heti, havi és éves számokra.
Mit kellett előbb ellenőrizni
Egy gyorsítótár csak akkor biztonságos, ha az, amit tárol, a kulcsának függvénye. Ez minden dizájnra vonatkozó állítás, és ellenőriztük, nem feltételeztük:
- egyik dizájn sem használja ezeket:
rand(),mt_rand(),shuffle()vagyuniqid() - egyik dizájn sem olvassa az órát óránál finomabb felbontásban
- a régi szkript követési paramétereit a kódbázisban sehol semmi nem olvassa
Ez utóbbi hozta az egész vállalkozás legszebb kudarcát. Amíg ezek a paraméterek még a kulcs részei voltak, minden kérés kissé eltérő egérkoordinátákat hordozott, így minden kulcs egyedi volt. A gyorsítótár egy teljes napig futott, és a mérlege ennyi lett: 13 találat. Tökéletesen működött, és semmit sem csinált, ami a hibák közül a legnehezebben észrevehető fajta.
És ha itt bármi hibázik — olvashatatlan könyvtár, megtelt lemez, sérült bejegyzés —, a kép egyszerűen a szokásos módon rajzolódik ki. Egy gyorsítótár soha nem lehet az oka annak, hogy egy számláló nem jelenik meg.