Cache nie naprawia wolnej aplikacji magicznie. Naprawia konkretny problem: zbyt częste wykonywanie tej samej pracy przez serwer. Jeżeli WordPress za każdym wejściem odpytuje bazę o te same ustawienia, Laravel liczy identyczny wynik w kontrolerze, a PHP przy każdym żądaniu od nowa kompiluje te same pliki, to nie jest „normalne obciążenie”. To strata czasu procesora, pamięci i połączeń do bazy.
Dobrze ustawiony Redis, Memcached i OPcache potrafią skrócić czas odpowiedzi strony, ale każdy z tych mechanizmów działa na innej warstwie. Redis i Memcached przechowują dane aplikacji w RAM-ie. OPcache przechowuje skompilowany kod PHP. Mieszanie tych pojęć prowadzi do złych decyzji: ktoś włącza Redis, oczekuje przyspieszenia wykonywania PHP, a prawdziwym hamulcem okazuje się brak OPcache albo za mały limit pamięci dla skryptów.
Gdzie cache faktycznie przyspiesza aplikację
Najpierw trzeba ustalić, co jest wolne. Cache ma sens wtedy, gdy aplikacja wielokrotnie odczytuje lub generuje te same dane. Typowe miejsca, w których zysk jest największy, to zapytania SQL, konfiguracja systemu, sesje, wyniki kosztownych obliczeń, fragmenty widoków oraz odpowiedzi API, których nie trzeba pobierać przy każdym żądaniu.
W praktyce wygląda to tak: użytkownik otwiera stronę produktu, aplikacja pobiera dane produktu, cenę, warianty, opinie, menu, ustawienia motywu i listę podobnych produktów. Bez cache każde wejście może oznaczać kilkanaście lub kilkadziesiąt zapytań do bazy. Z cache część odpowiedzi trafia z pamięci RAM, czyli bez pełnej ścieżki przez bazę, indeksy i silnik zapytań.
Nie wszystko warto buforować. Dane, które zmieniają się co kilka sekund, wymagają krótkiego TTL albo mechanizmu czyszczenia po zmianie. Dane konfiguracyjne, menu, słowniki, uprawnienia czy statyczne fragmenty strony mogą żyć w cache znacznie dłużej. Najgorszy wybór to ustawienie jednego czasu życia dla całej aplikacji, bo wtedy albo cache prawie nic nie daje, albo użytkownicy widzą nieaktualne treści.
Najrozsądniejsza kolejność działań:
- najpierw włącz i sprawdź OPcache, jeśli aplikacja działa na PHP;
- potem znajdź najcięższe zapytania do bazy i powtarzalne odczyty;
- dopiero następnie dobierz Redis albo Memcached;
- na końcu dopracuj czyszczenie cache po wdrożeniu, aktualizacji treści i zmianach konfiguracji.
W aplikacjach PHP największy błąd polega na zaczynaniu od najbardziej efektownego narzędzia. Redis brzmi poważniej niż OPcache, ale jeśli PHP kompiluje pliki przy każdym żądaniu, to aplikacja traci czas jeszcze zanim dojdzie do logiki biznesowej. OPcache powinien być standardem, nie dodatkiem „na później”.
Redis czy Memcached: wybór bez zgadywania
Redis i Memcached działają w pamięci RAM, ale nie są zamienne jeden do jednego. Memcached jest prostszy: zapisujesz wartość pod kluczem, ustawiasz czas życia i odczytujesz ją przy kolejnym żądaniu. To bardzo dobre narzędzie do prostego cache wyników zapytań, obiektów aplikacji i fragmentów stron. Ma mało warstw, mało decyzji i dobrze pasuje tam, gdzie cache ma być szybkim magazynem tymczasowym.
Redis jest cięższy funkcjonalnie, ale daje więcej kontroli. Obsługuje struktury danych, takie jak listy, zbiory, hashe i zbiory uporządkowane. Dzięki temu sprawdza się nie tylko jako cache, ale też jako magazyn sesji, kolejka zadań, licznik, mechanizm blokad, bufor zdarzeń albo element komunikacji między usługami. Jeżeli aplikacja potrzebuje czegoś więcej niż „zapisz i odczytaj tekstową wartość”, Redis zwykle wygrywa.
Granica decyzyjna jest prosta:
- wybierz Memcached, gdy cache ma przechowywać proste wartości, wynik SQL, HTML fragmentu albo obiekty serializowane bez dodatkowej logiki;
- wybierz Redis, gdy potrzebujesz struktur danych, kolejek, liczników, sesji, blokad, priorytetów albo bardziej świadomej polityki usuwania danych;
- nie używaj Redis jako „worka na wszystko”, jeśli nie masz monitoringu pamięci i zasad czyszczenia kluczy;
- nie wybieraj Memcached do danych, które muszą przetrwać restart albo wymagają bardziej złożonych operacji.
Konfiguracja pamięci jest ważniejsza niż sama decyzja o narzędziu. W Redis limit ustala się przez maxmemory, a zachowanie po osiągnięciu limitu przez maxmemory-policy. To właśnie ta polityka decyduje, czy Redis zacznie usuwać starsze klucze, klucze z TTL, najrzadziej używane elementy, czy zacznie odrzucać nowe zapisy. Redis opisuje te mechanizmy jako polityki eviction wybierane dyrektywą maxmemory-policy po osiągnięciu limitu maxmemory.
W Memcached parametr -m określa ilość RAM-u przeznaczoną na przechowywanie elementów, ale nie jest to pełny globalny limit procesu — Memcached może zużyć trochę więcej pamięci na narzuty własne. Dokumentacja Memcached wskazuje też, że ustawienie wartości poniżej 64 MB nadal może skończyć się użyciem do 64 MB jako minimum.
W hostingu współdzielonym dochodzi jeszcze jedno ograniczenie: nie zawsze masz pełny dostęp do konfiguracji demona. Panel może pozwalać jedynie włączyć Redis, wybrać wersję PHP i aktywować rozszerzenie. Wtedy decyzja jest mniej akademicka: sprawdzasz, co hosting faktycznie udostępnia, jaki jest limit pamięci, czy masz dostęp do statystyk i czy aplikacja potrafi bezpiecznie działać po utracie cache. Cache ma przyspieszać. Nie może być pojedynczym punktem awarii.
OPcache, TTL i czyszczenie: tu najczęściej ucieka wydajność
OPcache działa inaczej niż Redis i Memcached. Nie przechowuje danych aplikacji, tylko skompilowany kod bajtowy PHP. Gdy OPcache jest wyłączony, PHP musi przy żądaniu odczytać plik, sparsować go i przygotować do wykonania. Przy małej stronie różnica bywa niezauważalna. Przy WordPressie z wieloma wtyczkami, sklepie WooCommerce, Laravelu albo Symfony robi się z tego realny koszt.
Najważniejsze ustawienia OPcache to:
- opcache.memory_consumption — ilość pamięci współdzielonej dla OPcache, podawana w megabajtach;
- opcache.max_accelerated_files — liczba plików PHP, które mogą zostać zapisane w cache;
- opcache.validate_timestamps — kontrola, czy PHP ma sprawdzać zmiany w plikach źródłowych;
- opcache.revalidate_freq — częstotliwość sprawdzania zmian, gdy walidacja timestampów jest aktywna.
Oficjalna dokumentacja PHP opisuje opcache.memory_consumption jako rozmiar pamięci współdzielonej używanej przez OPcache, a minimalna dozwolona wartość to 8 MB. To nie znaczy, że 8 MB wystarczy. W większych aplikacjach taka wartość będzie za mała i doprowadzi do częstego wyrzucania skompilowanych skryptów z pamięci. Efekt: OPcache jest „włączony”, ale działa słabo.
Praktyczna zasada jest prosta: liczba plików PHP w projekcie powinna mieścić się w limicie opcache.max_accelerated_files, a pamięć OPcache nie powinna stale dobijać do limitu. W przeciwnym razie aplikacja będzie traciła czas na ponowne kompilowanie plików, choć administrator będzie przekonany, że problem został rozwiązany samym przełącznikiem „OPcache: on”.
Największe ryzyko przy OPcache dotyczy wdrożeń. Wyłączenie opcache.validate_timestamps poprawia wydajność, bo PHP nie sprawdza przy każdym cyklu, czy pliki się zmieniły. Ale wtedy po deployu trzeba ręcznie wyczyścić OPcache albo zrestartować odpowiedni proces PHP-FPM. Jeśli tego nie zrobisz, część użytkowników może dostać stary kod, a część nowy stan zależności. To nie jest drobna niedogodność. To prosta droga do błędów trudnych do odtworzenia.
Podobny problem dotyczy Redis i Memcached. Zbyt krótki TTL powoduje, że cache stale się odświeża i nie daje realnego odciążenia. Zbyt długi TTL zatrzymuje stare dane. W sklepie internetowym może to oznaczać nieaktualną cenę, błędną dostępność produktu albo koszyk, który zachowuje się inaczej niż panel administracyjny.
Najpierw trzeba buforować dane bezpieczne:
- konfigurację aplikacji;
- menu i elementy nawigacji;
- wyniki drogich, ale rzadko zmiennych zapytań;
- fragmenty widoków niezależne od konkretnego użytkownika;
- dane API z jasnym czasem ważności.
Ostrożniej należy traktować:
- ceny, stany magazynowe i promocje;
- koszyki zakupowe;
- uprawnienia użytkowników;
- panele administracyjne;
- dane personalizowane;
- tokeny, sesje i informacje bezpieczeństwa.
Warto też pilnować wielkości elementów. Memcached ma domyślny limit rozmiaru pojedynczego elementu na poziomie 1 MB, co wprost ogranicza sens przechowywania dużych serializowanych kolekcji jako jednego wpisu. Jeśli cache zaczyna przechowywać ogromne obiekty, to problem zwykle nie leży w braku pamięci, tylko w złym podziale danych.
FAQ
Czy Redis zawsze jest lepszy od Memcached?
Nie. Redis jest bardziej wszechstronny, ale Memcached bywa lepszy do prostego, szybkiego cache bez dodatkowej logiki. Jeśli aplikacja potrzebuje tylko zapisać i odczytać wynik zapytania, Memcached wystarczy. Jeśli potrzebne są sesje, kolejki, liczniki, blokady albo struktury danych, wybierz Redis.
Czy OPcache zastępuje Redis albo Memcached?
Nie. OPcache przyspiesza wykonywanie kodu PHP, a Redis i Memcached przyspieszają dostęp do danych. W aplikacji PHP te mechanizmy często powinny działać razem, bo rozwiązują różne problemy.
Jaki TTL ustawić dla cache?
Dla danych konfiguracyjnych i rzadko zmiennych można stosować dłuższy TTL, liczony w godzinach lub dniach. Dla cen, stanów magazynowych, rankingów i treści dynamicznych TTL powinien być krótki albo cache powinien być czyszczony po konkretnej zmianie. Najgorsze ustawienie to jeden uniwersalny TTL dla całej aplikacji.
Co sprawdzić, jeśli cache jest włączony, a strona nadal działa wolno?
Najpierw sprawdź, czy OPcache ma wystarczająco pamięci i nie przepełnia limitu plików. Potem zobacz statystyki trafień cache: hit ratio, liczbę usuwanych kluczy, wykorzystanie RAM-u i najwolniejsze zapytania SQL. Sam fakt, że Redis lub Memcached działa, nie oznacza jeszcze, że aplikacja z niego korzysta w miejscach, które naprawdę bolą.
Zacznij od najtańszego błędu do usunięcia: sprawdź, czy OPcache jest aktywny, ma sensowny limit pamięci i obejmuje wszystkie pliki PHP aplikacji. Dopiero potem ruszaj Redis albo Memcached. Jeśli od razu dokładasz cache danych bez uporządkowania OPcache, TTL i czyszczenia po deployu, możesz przyspieszyć jeden fragment strony, a jednocześnie zostawić w systemie największy hamulec.
