Contact met ondersteuning

Wij antwoorden per e-mail, meestal binnen twee dagen.

Google reCAPTCHA controleert deze inzending op misbruik; daarbij worden gegevens naar Google gestuurd. Het script laadt pas wanneer dit formulier wordt geopend.

← Alle berichten

Tellerafbeeldingen in het geheugen bewaren

Bijna een vijfde van de tellerafbeeldingen die deze dienst tekent, verandert niets meer. Een muisvolgscript uit de vorige generatie herlaadt de afbeelding bij elke beweging, en sinds die aanvragen niets meer omhoogbrengen, leveren twee ervan achter elkaar hetzelfde plaatje op, byte voor byte.

Een voor de hand liggende kandidaat voor een cache. De interessante besluiten waren waar hij moest komen en waar hij op gesleuteld moest worden.

Niet op de schijf

Dit draait op een kleine server, en de schijf is een SD-kaart. Getekende afbeeldingen daarnaartoe cachen zou ruwweg 70 MB schrijven per dag hebben betekend, in ruil voor een gemeten besparing van 1,6 minuut processortijd per dag.

Dat is een slechte ruil. SD-kaarten begeven het van schrijven, en wat je ervoor koopt is een afrondingsfout op een machine die niet door de processor wordt beperkt. De cache staat dus in /dev/shm, en dat is tmpfs, en dat is RAM. Daar gemeten: 0,027 ms om te lezen, 0,036 ms om te schrijven, 1,9 GB vrij.

wat het gekost zou hebben, per dag70 MBwat het opgeleverd zou hebben, per dag1,6 minmet opzet verschillende eenheden — dat is de ruil

Alles verdwijnt bij een herstart. Voor een cache is dat geen verlies, dat is het normale geval.

Op dezelfde machine draait Redis. Die is niet gebruikt, om een reden die niets met techniek te maken heeft: hij hoort bij een andere toepassing en is daarvoor met een wachtwoord beschermd. Eén exemplaar delen zou twee ongerelateerde diensten aan elkaar knopen, zodat een slechte dag voor de een een slechte dag voor de ander wordt.

De sleutel bevat de getallen

De gebruikelijke cachesleutel is een identiteit plus een vervaltijd, en de vervaltijd is een gok: er is de laatste vijf minuten niets belangrijks veranderd. Bij een teller is wat er verandert juist het ding dat te zien is.

Dus gaan de getoonde waarden in de sleutel. Verandert een getal, dan is het een andere sleutel, en wordt de afbeelding vers getekend. De gok verdwijnt in plaats van zorgvuldig gemaakt te worden. Elk geteld bezoek brengt op zijn minst het totaal over de levensduur omhoog, dus geen enkel geteld bezoek kan een verouderd plaatje krijgen. De vervaltijd die overblijft, is alleen een bovengrens voor de waarden die niet in de sleutel zitten — de week-, maand- en jaarcijfers.

Wat er eerst nagekeken moest worden

Een cache is alleen veilig als wat hij bewaart een functie is van zijn sleutel. Dat is een bewering over elk ontwerp, en ze is nagekeken in plaats van aangenomen:

  • geen enkel ontwerp gebruikt rand(), mt_rand(), shuffle() of uniqid()
  • geen enkel ontwerp leest de klok fijner dan per uur
  • de volgparameters van het oude script worden nergens in de boom gelezen

Die laatste leverde de mooiste mislukking van de hele oefening op. Zolang die parameters nog deel van de sleutel waren, droeg elke aanvraag iets andere muiscoördinaten mee, dus was elke sleutel uniek. De cache draaide een hele dag en noteerde 13 treffers. Hij werkte perfect en deed niets, en dat is de moeilijkst op te merken soort kapot.

En mislukt hier iets — onleesbare map, volle schijf, beschadigde vermelding — dan wordt de afbeelding gewoon op de normale manier getekend. Een cache mag nooit de reden zijn dat een teller niet verschijnt.

Advertentie