Kiedy pamięć podręczna rośnie w złą stronę

W katalogu pamięci podręcznej tej usługi leżą cztery małe pliki. Największy ma 35 bajtów. Razem zawierają trzy numery liczników i są czytane przy każdym pojedynczym wywołaniu licznika.

Istnieją po to, żeby ścieżka zliczania nie musiała zadawać bazie czterech pytań, na które prawie zawsze odpowiada „nie". Czy ten licznik wyklucza własne wizyty właściciela? Liczy kliknięcia wychodzące? Śledzi ścieżki po witrynie? Przeładowuje się sam? Dla ponad 99 % liczników każda odpowiedź brzmi nie, a plik z garstką numerów, przy których brzmi tak, jest tańszy do sprawdzenia niż cztery zapytania z indeksem.

Jest tańszy. Jest też tym rodzajem taniości, który się odwraca.

Co zmierzono

To samo pytanie — „czy ten licznik jest na liście?" — zadane na dwa sposoby, przy sześciu długościach listy. Droga przez plik: przeczytać, rozkodować JSON, poszukać numeru. Droga przez bazę: jedno przygotowane zapytanie do kolumny z indeksem. Po dwa tysiące powtórzeń, pięć rund, wzięta mediana.

Przy dzisiejszym rozmiarze plik wygrywa ośmiokrotnie: 0,0202 milisekundy wobec 0,1630. Przy tysiącu numerów są na równi. Przy dziesięciu tysiącach plik kosztuje dwanaście razy więcej, a przy stu tysiącach 135 razy więcej, bo trzeba wtedy przy każdym trafieniu przeczytać i rozkodować 578 kilobajtów.

Linia bazy się nie rusza. 0,16 milisekundy przy dwóch wierszach i 0,16 przy stu tysiącach: po to jest indeks, i łatwo zapomnieć, ile pracy kryje się za tak nudną linią.

Niewygodna część

Punkt przecięcia leży między 100 a 1000 numerów. Ta usługa ma 2 218 liczników, które miały ruch w ostatnich trzydziestu dniach.

Gdyby więc wykluczanie okazało się sukcesem — gdyby każdy, kto ma licznik, włączył „nie licz moich własnych wizyt" — plik zawierałby 2 218 numerów, ważył 11 kilobajtów i kosztował 0,43 milisekundy na trafienie zamiast 0,02. Przy wczorajszych 18 423 trafieniach to osiem sekund pracy dziennie, żeby uniknąć zapytania, które zajęłoby trzy.

Optymalizacja jest najszybsza wtedy, gdy funkcja jest najmniej używana. Nie psuje się stopniowo pod obciążeniem, jak wolne zapytanie. Psuje się wraz z upowszechnieniem, a to jedyna oś, na którą nikt nie patrzy, bo rosnące upowszechnienie ma być dobrą wiadomością.

Dlaczego mimo to zostaje

Bo dziś jest słuszne, a „dziś słuszne" wolno być powodem, dopóki ktoś zapisał, kiedy przestanie być prawdą.

Trzy numery w trzech plikach. Osiem razy taniej niż alternatywa, na maszynie, w której ścieżka zliczania jest jedyną rzeczą, która musi być szybka. Zastąpienie tego teraz zapytaniem, które pokonuje, dałoby gorszy system uzasadniony przypuszczeniem.

Brakuje potykacza, nie przebudowy. Plik i tak jest zapisywany z bazy, przez kod zmieniający ustawienie — właśnie tam zauważa się, że lista urosła ponad kilkaset wpisów, i to mówi. Pamięć podręczna ze spisanym pułapem to decyzja. Bez niego to zakład, na który nikt się nie zgodził.

Kształt ogólny

To nie jest argument przeciw trzymaniu pamięci podręcznej w pliku. To argument za wiedzą, w którą stronę ta pamięć rośnie.

Większość pamięci podręcznych pod obciążeniem robi się lepsza: więcej żądań, więcej trafień, lepszy stosunek. Ta jest z innego gatunku. Jej koszt na żądanie zależy od tego, ile w sobie mieści, a to, co mieści, rośnie razem z rzeczą, którą usługa chce zachęcać. Każde czytanie płaci za każdy wpis, także za te 2 215, które nie mają nic wspólnego z odwiedzającym liczonym właśnie teraz.

Pytanie do każdej tablicy wyszukiwania w pamięci albo w pliku nie brzmi „jak jest szybka", tylko „od czego rośnie i co się stanie, gdy tamto się powiedzie". Jeśli odpowiedź brzmi „zwolni", to granica rozmiaru należy do kodu, obok miejsca, które zapisuje plik, w dniu, w którym się go buduje.