Cache pełni istotną rolę w aplikacjach webowych. Od dawna przestał być traktowany jako doraźny środek zaradczy na problemy z wydajnością, a stał się jednym z kluczowym elementów wydajnej i skalowalnej architektury. Twórcy i miłośnicy Drupala są tego świadomi i dlatego kładą duży nacisk na rozwiązania związane z cachem. Obecnie standardowe rozwiązania pozwalają na cachowanie pojedynczych elementów, takich jak np. bloki czy zmienne, oraz całych stron. Rozwiązania te ułatwiają również innym modułom wykorzystywanie mechanizmów cache-owania poprzez udostępnianie prostego API. Praktyka pokazuje, że w wielu przypadach uruchamianie kolejnych warstw cache’u niekorzystnie wpływa na wydajność aplikacji opartej na Druplu. Niestety jest to jeden z tych problemów, które nie mają jednego uniwersalnego rozwiązania. Każdy przypadek należy rozpatrywać indywidualnie. Decyzja o uruchomieniu cacho-wania powinna mieć swoje uzasadnienie, a ewentualne korzyści powinny być potwierdzone w testach. Istotna jest również odpowiednia konfiguracja danego cache-u. Czasem jednak i to nie wystarcza. Doskonałym przykładem takiego stanu rzeczy jest domyślny plugin cache-u dostępny w module Views. Jego możliwości są mocno ograniczone i usatysfakcjonują nas tylko wtedy, gdy nie mamy zbyt wysokich wymagań. Dzieje się tak, ponieważ intencją twórców było to, by plugin poprawnie działał w jak najszerszym spektrum zastosowań, w jego implementacji widać pewne ustępstwa. Ustępstwa, którymi my, dobrze znając nas specyficzny przypadek, nie musimy się przejmować, tworząc plugin cache-u na własny użytek. Agenda:
- Jak działa cache we Views’ach?
- Co to są te klucze?
- Dlaczego czasem mogą szkodzić?
- Zmiany chcę widzieć NATYCHMIAST.
- Przykład ulepszonego pluginu.