Cache może skrócić czas odpowiedzi i zmniejszyć obciążenie baz danych lub usług zewnętrznych, ale sam z siebie nie naprawi nieefektywnego zapytania ani architektury z nieprawidłowo określonymi granicami. Strategia cache’owania w PHP powinna określać, co jest przechowywane, kto może to otrzymać, jak długo dane pozostają ważne oraz co się dzieje w razie awarii mechanizmu przechowywania.
Kryterium sukcesu nie jest wyłącznie zwiększenie współczynnika trafień. Aplikacja musi zachowywać reguły biznesowe, gdy cache jest pusty, nieaktualny lub niedostępny. Aby to osiągnąć, warto zacząć od zmierzenia problemu i traktować cache jako optymalizację o weryfikowalnym działaniu, a nie jako podstawowe źródło prawdy.
Najpierw zmierz, a dopiero potem zdecyduj, co przechowywać
Najpierw zidentyfikuj wolne ścieżki i ich przyczyny. Rejestruj czasy odpowiedzi dla endpointów, opóźnienia zapytań, wywołania usług zewnętrznych, użycie CPU i liczbę żądań. Analizuj nie tylko średnie, lecz także wysokie percentyle: akceptowalna średnia może ukrywać bardzo wolne odpowiedzi dla części użytkowników.
Szukaj powtarzających się operacji, których wynik zmienia się rzadziej, niż jest pobierany: katalogów, publicznej konfiguracji, opublikowanych treści lub kosztownych agregacji. Sprawdź też, czy źródłem opóźnień nie są zapytania bez indeksów, nadmiar żądań, serializacja albo powtarzanie tej samej pracy w ramach jednego żądania. Usprawnienie zapytania może być lepszym rozwiązaniem niż przechowywanie wyniku, który trudno unieważnić.
Przed wprowadzeniem zmiany ustal punkt odniesienia: wydajność, obciążenie i obserwowaną jakość danych. Następnie porównaj ten sam ruch lub powtarzalny test. Jeśli nie da się przypisać poprawy cache’owi, trudno będzie ocenić jego koszt operacyjny i skutki uboczne.
Wybierz między cache’em aplikacyjnym, HTTP i cache’owaniem zapytań
Cache aplikacyjny przechowuje wartości, które kod PHP może ponownie wykorzystać, na przykład wyniki zapytań lub obliczone odpowiedzi. Może działać w pamięci współdzielonej, dedykowanej usłudze lub innym backendzie zgodnym z aplikacją. Sprawdza się, gdy wiele żądań potrzebuje tego samego wyniku i można precyzyjnie określić jego zakres oraz okres ważności.
Cache HTTP wykorzystuje dyrektywy takie jak Cache-Control, ETag i walidatory, aby przeglądarki lub pośrednicy mogli ponownie wykorzystywać odpowiedzi. Jest przydatny w przypadku zasobów publicznych lub odpowiedzi, których polityka prywatności dopuszcza przechowywanie. Odpowiedzi spersonalizowane wymagają szczególnej ostrożności: polityka publiczna może ujawnić dane, natomiast polityka prywatna lub zakazująca przechowywania może ograniczyć takie ryzyko — zależnie od przepływu danych i zaangażowanych pośredników.
Cache zapytań może być funkcją bazy danych, sterownika lub warstwy przechowującej wyniki. Nie należy go mylić z optymalizacją dostępu do danych: cache nie zastępuje indeksów, odpowiednich planów zapytań ani transakcji. Przed jego włączeniem ustal, kto unieważnia wpisy i czy odczyty muszą natychmiast odzwierciedlać zapisy.
Wybierz warstwę najbliższą problemowi, zamiast włączać wszystkie naraz. Nakładanie cache’y bez jawnego modelu może sprawić, że różne warstwy będą przechowywać różne wersje tych samych danych i utrudnić diagnozowanie problemów.
Zaprojektuj klucze, zakres i czas wygaśnięcia
Klucz musi identyfikować wszystkie czynniki zmieniające wynik. Na przykład odpowiedź z katalogiem może zależeć od języka, waluty, regionu i wersji danych. Uwzględnij te elementy w stabilny i czytelny sposób, aby ułatwić diagnostykę; nie umieszczaj w kluczu danych wrażliwych.
Jeśli wynik zależy od użytkownika, roli, uprawnień lub organizacji, izolacja musi to uwzględniać. Klucz zawierający wyłącznie nazwę ścieżki może spowodować, że spersonalizowana odpowiedź trafi do innej osoby. Sprawdź też, w jaki sposób wpisy są współdzielone między procesami i serwerami. Jeśli nie możesz wiarygodnie wyliczyć wszystkich wymiarów wpływających na wynik, nie przechowuj tej odpowiedzi we współdzielonym cache’u.
Czas wygaśnięcia powinien wynikać z reguły biznesowej, a nie z arbitralnie wybranej wartości. Konfiguracja zmieniająca się rzadko może tolerować dłuższy okres niż saldo konta lub stan rezerwacji. Określ maksymalny dopuszczalny czas nieaktualności i rozważ losowe różnicowanie terminów wygaśnięcia, gdy wiele podobnych wpisów może wygasnąć jednocześnie.
Wygaśnięcie po upływie określonego czasu nie zastępuje unieważniania po istotnych zmianach. Jest to ostateczny limit, który zapobiega bezterminowemu przechowywaniu wpisu, a nie gwarancja natychmiastowej aktualizacji.
Aktualizuj i unieważniaj wpisy, gdy zmienia się źródło danych
Wybierz mechanizm odpowiedni do wymaganej spójności. Jawne unieważnienie można wykonać po zapisie; jest proste, ale może się nie powieść, jeśli proces zostanie przerwany między zapisaniem danych a usunięciem wpisu z cache’a. Alternatywą jest użycie wersji w kluczach: po zmianie źródła zwiększa się wersję, a wcześniejsze wpisy przestają być odczytywane. Wymaga to prawidłowego zarządzania wersją.
W systemach opartych na zdarzeniach zatwierdzona zmiana może opublikować powiadomienie służące do unieważnienia lub ponownego obliczenia danych pochodnych. Jeśli dostarczanie zdarzeń nie jest niezawodne, uwzględnij ponawianie prób, idempotencję i mechanizm uzgadniania stanu. Nie zakładaj, że aktualizacja bazy danych i usługi cache stanowią operację atomową.
W przypadku danych dopuszczających krótkotrwałą nieaktualność można serwować wygasły wpis podczas jego aktualizacji w tle. Ta technika nie nadaje się do wszystkich informacji: określ, które dane się kwalifikują, jak długo może trwać ich nieaktualność i co się stanie w razie niepowodzenia aktualizacji. Decyzja powinna wynikać z wpływu, jaki ma wyświetlenie wcześniejszej wartości.
Określ bezpieczne zachowanie w razie awarii
Przetestuj trzy różne stany: brak wpisu, wygasły wpis i niedostępny backend. Dla każdego z nich zdecyduj, czy aplikacja ponownie obliczy wynik na podstawie źródła, zwróci kontrolowany błąd, czy — jeśli jest to bezpieczne — udostępni wcześniejszą wartość. Pusty cache powinien być normalnym stanem początkowym, który nie powoduje nieprawidłowych wyników.
Chroń źródło danych przed awarią backendu. Jeśli każde żądanie uruchamia kosztowne zapytanie po wygaśnięciu tego samego klucza, może dojść do lawinowego wzrostu obciążenia. Możliwe środki zaradcze obejmują ograniczenie równoległego ponownego obliczania, tymczasowe ponowne wykorzystanie bezpiecznych wartości albo stosowanie limitów i timeoutów. Rozwiązanie zależy od tego, czy dane mogą być serwowane jako nieaktualne, oraz od wydajności źródła.
Rejestruj błędy, opóźnienia oraz niepowodzenia odczytu i zapisu, nie uwzględniając wartości prywatnych. Cache jest zwykle zależnością wpływającą na wydajność, a nie źródłem prawdy o danych. Jeśli jego niedostępność ma zatrzymywać krytyczną operację, taką decyzję należy wyraźnie uzasadnić.
Weryfikuj spójność i wydajność za pomocą powtarzalnych testów
Porównaj scenariusze z wyłączonym, zimnym i ciepłym cache’em. Uwzględnij pierwsze żądanie po zapisie, zmianę języka lub uprawnień, jednoczesne wygaśnięcie wpisów oraz awarię backendu. Sprawdź zarówno treść odpowiedzi, jak i izolację: dwaj użytkownicy o różnych uprawnieniach nie mogą otrzymywać nawzajem swoich odpowiedzi.
Używaj testów automatycznych do weryfikacji istotnych reguł dotyczących kluczy i unieważniania oraz testów integracyjnych, aby sprawdzić działanie z rzeczywistym backendem lub reprezentatywnym zamiennikiem. Podczas testów obciążeniowych obserwuj trafienia i chybienia, opóźnienie cache’a, operacje ponownego obliczania, obciążenie źródła i błędy. Wysoki współczynnik trafień nie dowodzi, że odpowiedzi są poprawne.
Wdrażając zmianę, porównuj metryki i liczbę błędów z punktem odniesienia. Zachowaj możliwość wyłączenia optymalizacji lub powrotu do bezpiecznego zachowania, jeśli pojawią się nieaktualne dane, wzrost zużycia pamięci lub nieoczekiwane obciążenie bazy danych.
Lista kontrolna obsługi cache’a
- Zmierzone problemy: znane są ścieżki i operacje uzasadniające użycie cache’a.
- Zdefiniowane dane i źródło: cache nie jest traktowany jako podstawowy rejestr danych.
- Kompletny klucz: uwzględnia istotne wymiary funkcjonalne i uprawnienia.
- Uzasadniony czas wygaśnięcia: odpowiada biznesowej tolerancji na nieaktualność.
- Zaplanowane unieważnianie: określono, jakie zdarzenie aktualizuje lub zastępuje każdy wpis.
- Uwzględnione awarie: zdefiniowano zachowanie dla pustego, wygasłego i niedostępnego cache’a.
- Monitorowanie operacyjne: śledzone są opóźnienia, błędy, trafienia i obciążenie źródła.
- Testy izolacji: weryfikowani są użytkownicy, role, języki i inne istotne konteksty.
Solidna strategia cache’owania ogranicza powtarzaną pracę, nie zmieniając nieświadomie znaczenia danych. Jeśli każdy wpis ma jasno określony zakres, politykę ważności i sprawdzony plan działania na wypadek awarii, zespół może ocenić korzyści oraz wycofać lub dostosować optymalizację, gdy przestanie być odpowiednia.
