Problemy z cachem

Pisałem ostatnio możliwościach jakie daje mechanizm cachowania w CakePHP. Daje on wiele możliwości jednak trzeba się nim umiejętnie posługiwać.

W poście http://www.reboo.pl/2009/11/30/jak-przyspieszyc-aplikacje-w-cakephp/ napisałem 5 ustawień Cake’a, na przyśpieszenie jego pracy. Niestety niosą one za sobą kilka problemów, o których należy pamiętać.

Ustawienie trybu debug na 0 i wyłączenie Cache.disable.
Jak pisałem, tryb debug 0 powoduje odczytywanie pewnych informacji z plików w katalogu tmp. Po zmianie struktury bazy danych należy wyczyścić podkatalog tmp/cache/models. Jeśli się o tym zapomni, skutki mogą być tragiczne. Np. po dodaniu numeru telefonu do formularza (w formie nowej kolumny w tabeli), dane z tego pola nie zostaną w ogóle zapisane w bazie, ponieważ polecenie DECSRIBE tabeli znajdujące się w cache, nie będzie zawierało informacji o tym nowym polu, więc zostanie ono odrzucone przy zapisie.
Cache zapytań w modelu.
O tym z kolei trzeba pamiętać wykonując zapytania w pętlach, np. dodając rekord a potem ponownie odczytując listę wszystkich rekordów w bazie.
Cache modeli w kontrolerze.
Ustawienie modelu jako presistent w kontrolerze powoduje jego serializację i zapisanie w pliku. Po dodaniu nowych funkcji, czy właściwości do modelu, trzeba także wyczyścić podkatalog tmp/cache/presistent.
Klasa Cache.
Klasa ta jest dość prosta w użyciu. Można w niej zapisać np. listę wszystkich kategorii na nieokreślony czas. Trzeba tylko pamiętać, żeby ją zaktualizować przy modyfikacji bazu. Można także ręcznie wyczyścić cały cache przez wywołanie funkcji Cache::clear().
Cache widoków.
Ten mechanizm może znacznie zmniejszyć obciążenie aplikacji. Kiedy wywoływana jest akcja, która ma zostać zapisana w cache, Cake sprawdza najpierw, czy istnieje aktualny plik z gotowym widokiem. Jeśli tak, całe wykonanie akcji jest pomijane i zwracany gotowy już plik. Część widoku może zawierać dynamiczne bloki <cake:nocache>. Niestety można w nich używać tylko danych np. z sesji z helpera session, do pozostałych danych nie ma dostępu, ponieważ jak pisałem wcześniej, cała akcja kontrolera nie jest wykonywana. Drugi problem pojawia się wtedy, gdy bloku tego użyjemy w layoucie (np. do pola logowania). W akcjach, które nie są zapisywane w cache blok ten zostanie umieszczony w kodzie HTML. Niczemu to nie przeszkadza, ale mogą się znaleźć osoby, które nie chcą zdradzać nawet najmniejszych szczegółów działania aplikacji.
W poprzednim pości pisałem także, że zmiany w modelu powodują wyczyszczenie pamięci cache dla widoków. Niestety dzieje się tak jedynie dla kontrolera o tej samej nazwie. Więc gdy korzystamy z modelu User w kontrolerze PostsConroller i aktualizujemy dane użytkownika, które powinny pokazać się w postach, musimy ręcznie wyczyścić widoki dla tego kontrolera przez wywołanie funkcji cacheClear(‘controler’), gdzie controler to oczywiście nazwa kontrolera.