Cache hit ratio
Cache trafiający w 98% przypadków działa błyskawicznie; przy 60% niewiele to zmienia. Ten kalkulator zamienia liczbę trafień i chybień na wskaźnik hit ratio, miss rate oraz łączną liczbę żądań — liczby, które pokazują, czy warstwa cache faktycznie odciąża backend.
Wynik
Wprowadź dane i kliknij Oblicz.
Co mierzy cache hit ratio
Cache hit ratio to odsetek żądań obsłużonych z cache bez sięgania do wolniejszego origin (baza, dysk, API, origin CDN). Hit = odpowiedź z cache; miss = trzeba było pobrać lub policzyć dane od nowa. Liczysz go zawsze w konkretnym oknie czasu — ostatnia godzina, dzień albo okres między deployami.
Dlaczego hits i misses muszą być z tego samego okna
Wskaźnik ma sens tylko wtedy, gdy obie liczby pochodzą z tego samego okresu i tej samej warstwy cache. Hits z dnia i misses z godziny dają fałszywy obraz. Podobnie: mieszać metryki CDN edge z Redisem albo sumować kilka klastrów bez jasnej definicji „żądania”.
- Używaj tej samej etykiety czasu w Prometheusie / panelu CDN.
- Po restarcie cache (zimny start) hit ratio chwilowo spada — to niekoniecznie regresja konfiguracji.
- Porównuj „jabłka do jabłek”: ten sam endpoint, ten sam region, ten sam typ treści.
Offload, latencja i koszt origin
Każdy miss to dodatkowe opóźnienie i obciążenie origin. Przy 90% hit ratio backend obsługuje 10% ruchu; przy 99% — 1%. Skok z 90% do 99% to więc 10× mniej wywołań origin, nie „tylko 9 punktów procentowych”.
- Offload — mniej żądań do origin = niższe CPU, I/O i rachunki za egress.
- Latencja — hit z pamięci/edge jest zwykle o rzędy wielkości szybszy niż miss.
- Koszt — przy płatnym origin (API, baza zarządzana) każdy punkt procentowy missów ma realną cenę.
TTL, pojemność, eviction i klucze
- TTL — dłuższy TTL zwykle podnosi hit ratio, ale zwiększa ryzyko stale data; krótszy TTL „świeży” dane kosztem więcej missów.
- Pojemność — za mały cache wypycha gorące klucze (eviction) zanim zdążą się przydać.
- Eviction (LRU/LFU) — zła polityka albo burza unikalnych kluczy obniża hit ratio mimo „dużego” limitu RAM.
- Projekt kluczy — zbyt szczegółowe klucze (np. zbędne query params) rozdrabniają ruch i zabijają współdzielone hit’y.
Warstwy: CDN, aplikacja, baza, przeglądarka
- CDN / edge — cel często 95–99%+ dla statycznych assetów; wysoki hit ratio = mniej ruchu do origin.
- Cache aplikacji (Redis, Memcached) — typowo 70–90% przy dynamicznych danych.
- Cache zapytań DB — pomaga przy powtarzalnych odczytach; nie zastępuje indeksów.
- Cache przeglądarki — lokalny dla użytkownika; nie widać go w metrykach serwera.
Przykłady
- 900 hitów, 100 missów → hit ratio 90%, miss rate 10%, 1000 żądań. Backend wciąż obsługuje co 10. żądanie.
- Niski wskaźnik 40% (400 hitów, 600 missów) — typowe przyczyny: za mały cache, zbyt krótki TTL, klucze z session-id / zbędnymi parametrami, zimny start po deployu.
- Przed / po: 600/400 (60%) → po wydłużeniu TTL i ujednoliceniu kluczy 950/50 (95%). Origin load spada z 40% do 5% ruchu.
FAQ — cache hit ratio
- Jaki hit ratio jest dobry dla CDN?
- Dla statycznych assetów (CSS, JS, obrazy, wideo) typowy cel to 95–99%+. Dla HTML lub spersonalizowanych odpowiedzi bywa niższy — ważne, by mierzyć osobno per typ treści.
- Dlaczego hits i misses wyglądają niespójnie?
- Najczęściej pochodzą z różnych okien czasu, różnych warstw (CDN vs Redis) albo innych definicji żądania. Zawsze bierz obie liczby z tego samego źródła i okresu.
- Czy dłuższy TTL zawsze poprawia hit ratio?
- Zwykle tak, ale nie zawsze warto: dłuższy TTL zwiększa ryzyko nieświeżych danych. Przy często zmieniających się danych lepszy bywa krótszy TTL + cache warming kluczowych wpisów.
- Czy bardzo duży cache może zaszkodzić?
- Tak — ogromny cache z chaotycznymi kluczami traci więcej czasu na zarządzanie i eviction, a hit ratio i tak może być niski. Najpierw napraw klucze i TTL, potem zwiększaj pojemność.
- Jaki hit ratio jest „dobry” w cache aplikacji?
- Dla dynamicznych danych 70–85% bywa już sensowny; 90%+ jest świetny, ale zależy od zmienności danych i wzorca ruchu.
- Dlaczego hit ratio spada po restarcie Redis / Memcached?
- Cache w pamięci jest zimny po restarcie — trzeba warming albo poczekać, aż ruch go wypełni. To normalne, niekoniecznie błąd konfiguracji.
- Czy ten kalkulator pokazuje trend w czasie?
- Nie — liczy jednorazowy wskaźnik z podanych liczb. Trend wymaga monitoringu (Prometheus, Grafana, panel CDN) zbierającego hits/misses okresowo.
- Co to jest miss rate?
- Miss rate = 100% − hit ratio. To ta sama informacja z drugiej strony — ile żądań trafia do origin.