[Drupal 6/Views] Jak podrasować pamięć podręczną modułu Views?

Data dodania wpisu: 15-09-2011

Podstrony albo bloki generowane z Viewsów w Drupalu zbyt długo się ładują? Odświeżanie pamięci podręcznej w nieodpowiednich momentach irytuje? Jeśli tak, to moduł Views Content Cache jest dla Ciebie;)

 

Dzięki modułowi Views Content Cache przechowywanie pamięci podręcznej widoków zyskuje zupełnie nowego wymiaru. Już nie musimy ustalać sztywnego wymiaru czasu przechowywania wyników zapytania i wygenerowanego kodu HTML widoku na określoną ilość czasu.

 

Teraz można w prosty sposób ustawić maksymalny czas przechowywania pamięci podręcznej na np. 6 dni, i jednocześnie ustalić, w jakiej sytuacji cache będzie odświeżony przed upłynięciem tego czasu. Do wyboru mamy takie opcje, jak wprowadzenie nowego wpisu do określonego typu zawartości, dodanie nowego komentarza, czy też wprowadzenie oceny wpisu przez VotingAPI.

 

Views

 

 

Views

 

 

Views

 

Proste podsumowanie dla zwykłej strony z listingiem Aktualności dostępnej na jednym z portali, który miałem okazję wdrażać; wyniki podane przez moduł Devel, before (niższy rekord) - after (wyższy rekord) - przy wyłączonych Drupalowych mechanizmach cache (tylko Views Content Cache w akcji):

 

Ścieżka Memory (MB) ms (Total) # Queries Query ms
aktualnosci.html 48.75 975 181 45
aktualnosci.html 59.00 1682 222 91

 

A co byłoby przy większej ilości widoków do wygenerowania i przy włączonym Drupalowym cache i innych bajerach - odpowiedzcie sobie sami :)

 

Dla posiadaczy Drupala 7 można pobawić się jeszcze modułem Cache Actions, sponsorowanym przez NodeOne, choć sam nie miałem jeszcze czasu i okazji go przetestować. Jak nadejdzie taka chwila, z pewnością podzielę się doświadczeniami :)

 

EDIT 22.09.2011:

 

Ostatnio przeprowadziłem testy na innym serwerze i śmiem twierdzić, że profity z używania tego modułu są zależne od konfiguracji, tudzież mocy obliczeniowej serwera - ale to akurat tyczy się nie tylko tego modułu, ale i np. standardowej pamięci podręcznej widoku.

 

Generalnie możliwe jest, że jeśli serwer ma niską moc obliczeniową, za to dość wydajną bazę danych, to możliwe, że szybciej zostanie zrealizowane zapytanie bez korzystania z cache, niż pobieranie danych z pamięci podręcznej i generowanie danych z tego zbioru. 

 

Zatem ta uwaga nie dotyczy stricte samego modułu, ale ogólnie stosowania pamięci podręcznej w widokach, których wyniki nieraz są dość obszerne.

 

Dlatego też zanim moduł Views Content Cache zostanie użyty w wersji produkcyjnej, radzę sprawdzić porównanie statystyk z Devel'a na serwerze, na którym moduł instalujemy, bo niestety, ale zależnie od konfiguracji serwera może być lepiej, a może być gorzej. Lepiej jest na serwerach linuxpl.com. Gorzej - nie chciałbym robić negatywnej reklamy, bo raczej pałam pozytywnym stosunkiem do tej firmy, a to może jest po prostu mała wpadka - nie zawsze można dostosować maszynę do każdych warunków;)

Komentarze

Nie miałem okazji testować tego na argumentach, jak przydarzy się okazja to podzielę się raportem (bo obecnie obłożenie robotą dość mocne i średnio mam ochotę testować różne ciekawostki;))
Hej, dzięki za przypomnienie modułu, oglądałem go z czasów 1. wersji.

Wiesz może, jak zachowuje się z widokami z argumentami?

Pozdrowienia.
Comments closed...

DesignEnd na Facebook'u

Inspiration