Przykład 1
- 950 trafień
- 50 chybień
95.0%
Jaki cache hit ratio przy 950 i 50? 95.0%. Requesty, nie byte-hit.
Cache hit ratio
Wpisz trafienia i chybienia. 950 i 50 dają 95.0%. 800 i 200 dają 80.0%. 99 i 1 dają 99.0%. To hit ratio requestów, nie udział bajtów.
To liczba requestów: trafienia / (trafienia + chybienia). Nie byte-hit i nie wolumen GB. Koszt wywołań jest na koszcie na request.
Wynik
Wprowadź dane i kliknij Oblicz.
Jak to działa?
Cache hit ratio w tym kalkulatorze to liczba requestów. 950 trafień i 50 chybień dają 95.0%. 800 i 200 dają 80.0%. 99 i 1 dają 99.0%. Wzór to trafienia / (trafienia + chybienia) × 100. To nie byte-hit i nie udział gigabajtów z cache.
Hit to request obsłużony z cache. Miss to request, który poszedł dalej. 95.0% przy 950 i 50 znaczy, że 50 z 1000 requestów omija cache. Kalkulator nie waży odpowiedzi w bajtach. Duży miss i mały hit liczą się tak samo.
Obie liczby muszą być z tego samego okna. Trafienia z dnia i chybienia z godziny psują stosunek. Warstwa CDN i Redis to dwa osobne hit ratio. Tu wpisujesz jedną parę liczb.
Koszt na request obok mnoży cenę za milion przez liczbę wywołań. Tu zostaje sam odsetek. 95.0% nie jest fakturą. 80.0% przy 800 i 200 to wciąż 200 requestów poza cache.
Wpisz 950 i 50, potem Oblicz. Wynik to 95.0%. Przecinek w 950,5 działa. Zero w obu polach nie daje stosunku, bo nie ma dzielenia przez zero.
950 i 50 dają 95.0%. 800 i 200 dają 80.0%. 99 i 1 dają 99.0%. Inna para requestów daje inny hit ratio.
Wzór
hit ratio = trafienia / (trafienia + chybienia) × 100
Jak korzystać
- Wpisz trafienia 950 i chybienia 50.
- Kliknij Oblicz. Hit ratio to 95.0%.
- 800 i 200 dają 80.0%. 99 i 1 dają 99.0%.
- To liczba requestów, nie byte-hit.
- Sąsiednia kalkulator liczy koszt tych wywołań, nie odsetek.
950 i 50 dają 95.0%
Hit ratio = trafienia / (trafienia + chybienia). 950 i 50 dają 95.0%. To requesty, nie byte-hit.
- Cache
- Warstwa, z której liczysz requesty. 950 i 50 dają 95.0%. Nie GB.
- hit
- Request z cache. 99 i 1 dają 99.0%. To nie udział bajtów.
- ratio
- Odsetek requestów. 800 i 200 dają 80.0%. Nie byte-hit.
Przykłady
Przykład 2
- 800 trafień
- 200 chybień
80.0%
Jaki hit ratio przy 800 i 200? 80.0%. 200 requestów poza cache.
Przykład 3
- 99 trafień
- 1 chybienie
99.0%
Jaki hit ratio przy 99 i 1? 99.0%. Nadal liczba requestów.
Powiązane kalkulatory
Najczęstsze pytania
Jaki cache hit ratio przy 950 i 50?
95.0%. 950 / 1000 requestów. To nie byte-hit.
Ile przy 800 i 200?
80.0%. 200 z 1000 requestów idzie poza cache.
Ile przy 99 i 1?
99.0%. 99 / 100 requestów. Nadal liczba żądań.
Czy to byte-hit ratio?
Nie. Kalkulator liczy requesty. Duża odpowiedź i mała liczą się tak samo.
Czy 95.0% to GB z cache?
Nie. To odsetek requestów. Wolumen bajtów jest poza tym kalkulatorem.
Czy można mieszać CDN i Redis?
Nie w jednym wpisie. Jedna para liczb, jedna warstwa, jedno okno.
Co przy zerze w obu polach?
Nie ma stosunku, bo nie dzielimy przez zero. Wpisz choć jedno żądanie.
Czy przecinek w 950,5 działa?
Tak. 950,5 i 50 dają inny hit ratio niż 950 i 50.
Czym to różni się od kosztu na request?
Tam cena / 1e6 × liczba. Tu 950 i 50 zostają 95.0%.
Źródła wiedzy
Kalkulator liczy bity, bajty albo przepustowość z Twoich liczb. Poniżej definicje bitu i SI (GUM).
Strona zaktualizowana w 2026.
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.