Wielu z nas mogło spotkać się z sytuacją, gdy dispatcher używa starej wersji kodu. Ten artykuł opisuje, jak tego uniknąć, jednocześnie wykorzystując możliwości buforowania Dispatchera.
Unieważnianie to mechanizm identyfikacji przestarzałych zasobów w pamięci podręcznej. Istnieją narzędzia do automatycznego i ręcznego unieważniania. Ustawmy początkową konfigurację sekcji unieważniania pliku konfiguracyjnego Dispatchera, następnie dowiedzmy się, jak unieważnianie działa na niskim poziomie, a na koniec powróćmy do analizy narzędzi do unieważniania. Ale najpierw podstawy.
Czym jest pamięć podręczna Dispatcher w AEM?
Dispatcher to narzędzie AEM do buforowania i równoważenia obciążenia, które przechowuje pliki z pamięci podręcznej na serwerze WWW w ten sam sposób, co statyczna strona internetowa. Po zażądaniu, dokument podlegający buforowaniu jest sprawdzany przez Dispatchera w celu ustalenia, czy ten dokument istnieje w systemie plików serwera WWW:
- Jeśli dokument jest w pamięci podręcznej, Dispatcher zwraca plik.
- Dispatcher żąda dokumentu z instancji AEM, jeśli nie jest on w pamięci podręcznej.
Dostarczanie danych z pamięci podręcznej Dispatchera zmniejsza obciążenie instancji publikujących AEM.
/cache
{
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
}
Jak wyczyścić pamięć podręczną Dispatchera?
Istnieją co najmniej 3 sposoby na wyczyszczenie pamięci podręcznej Dispatchera:
- Za pomocą agentów opróżniania na instancjach autorskich i/lub publikujących
- Ręczne opróżnianie
- Niestandardowy kod do programowego opróżniania
Ustawienia początkowe sekcji unieważniania
Przejdźmy teraz do unieważniania stron z pamięci podręcznej AEM. Blok /invalidate w sekcji /cache określa pliki z pamięci podręcznej, które mogą być automatycznie unieważniane po zaktualizowaniu zawartości. Na przykład, poniższa konfiguracja unieważnia wszystkie strony HTML:
/cache
{
/invalidate
{
/0000 { /glob "*" /type "allow" }
}
}
W przypadku automatycznego unieważniania, Dispatcher nie usuwa plików z pamięci podręcznej po zaktualizowaniu zawartości, ale sprawdza ich ważność przy kolejnym żądaniu. Dokumenty w pamięci podręcznej, które nie są automatycznie unieważniane, pozostaną w pamięci podręcznej, dopóki nie zostaną usunięte podczas aktualizacji zawartości. Na przykład, zezwólmy na automatyczne unieważnianie całej pamięci podręcznej:
Uruchom ponownie serwer httpd po zaktualizowaniu sekcji /invalidate , aby zastosować nowe zmiany.
Unieważnianie w szczegółach
Dispatcher używa specjalnych pustych plików domyślnie nazywanych „.stat” na niskim poziomie. Parametr /statfileslevel „0” jest domyślnie ustawiony, co oznacza, że używany jest tylko jeden plik .stat znajdujący się w katalogu głównym folderu htdocs . Jeśli czas zmiany pliku .stat jest późniejszy niż czas zmiany zasobu, dispatcher uznaje taki zasób za nieaktualny lub nieważny.
Na przykład, mamy następujące zasoby z pamięci podręcznej po zażądaniu strony http://localhost/content/geometrixx/en/products.html :
Unieważnijmy je, stosując niskopoziomowy mechanizm plików .stat. Utwórz pusty plik o nazwie „.stat” w katalogu głównym swojego katalogu htdocs:
Możesz zauważyć, że czas zmiany pliku .stat jest późniejszy niż czas zasobów z pamięci podręcznej. Dla dispatchera oznacza to, że wszystkie zasoby są nieaktualne. To jest niskopoziomowy mechanizm unieważniania. Jeśli ponownie odwiedzimy http://localhost/content/geometrixx/en/products.html po utworzeniu tego pliku .stat, żądane zasoby z pamięci podręcznej zostaną zaktualizowane:
Ten przykład ilustruje wzorzec unieważniania z domyślnym parametrem /statfileslevel „0”. Zobaczmy, jak możemy bardziej szczegółowo dostroić unieważnianie za pomocą parametru /statfileslevel .
Ustawianie /statfileslevel
Możesz użyć właściwości /statfileslevel pliku konfiguracyjnego dispatchera, aby selektywnie unieważnić pliki z pamięci podręcznej zgodnie z ich ścieżką. Istnieją pewne zasady dotyczące mechanizmu właściwości /statfileslevel:
- Dispatcher tworzy pliki .stat w każdym folderze, począwszy od docroot aż do określonego poziomu. Poziom folderu docroot wynosi 0.
- Po zaktualizowaniu pliku, dispatcher znajduje folder znajdujący się na poziomie statfileslevel i unieważnia wszystkie pliki w tym folderze oraz wszystkie pliki znajdujące się poniżej w tym folderze.
- Jeśli poziom zaktualizowanego pliku jest niższy niż statfileslevel, wówczas tylko pliki folderu zawierającego zaktualizowany plik są unieważniane, ale pliki leżące niżej w tym folderze pozostają ważne.
- Podczas aktualizacji pliku, wszystkie pliki odpowiadającego folderu i powyżej, aż do poziomu głównego (włącznie), zostaną unieważnione.
Przyjrzyjmy się kilku przykładom, aby lepiej zrozumieć zasady właściwości /statfileslevel. Nasz domyślny przypadek demonstracyjny, w którym /statfileslevel wynosi „0”, wygląda następująco:
W głównym folderze docroot znajduje się tylko jeden plik stat. Obszar odpowiedzialności lub zakres tego pliku stat będzie obejmował całe drzewo plików naszego docroot. Jeśli jakiś plik w drzewie ma datę modyfikacji starszą niż data modyfikacji pliku stat, dyspozytor uzna ten plik za unieważniony.
Jeśli ustawimy /statfileslevel na „4”, unieważnianie działa w następujący sposób:
Pliki stat istnieją na wszystkich poziomach od 0 (główny) do 4.
Plik stat na poziomie niższym niż 4 ma zakres lub obszar odpowiedzialności tylko dla folderu, który go zawiera. Jeśli plik stat w folderze content/geometrixx/en jest nowszy niż jakikolwiek plik z tego folderu, wówczas ten plik jest unieważniony, ale wszystkie pliki z innych folderów są określane przez inne pliki stat.
Tylko pliki stat o wartości statfileslevel (w naszym przypadku poziom to 4) mają zakres lub obszar odpowiedzialności dla całego podrzędnego drzewa, zaczynając od folderu zawierającego taki plik stat i rozciągając się w dół do niższych poziomów drzewa plików.
Zatem jeśli plik stat w folderze content/geometrixx/en/products ma nowszy czas modyfikacji niż jakikolwiek plik w podrzędnym drzewie plików, które obejmuje folder products, dyspozytor uzna ten plik za unieważniony. Walidacja wszystkich plików, które nie znajdują się w tym drzewie, jest określana przez inne pliki stat.
Automatyczne unieważnianie i agent czyszczący Dispatcher AEM
Aby zautomatyzować unieważnianie, możesz włączyć agenty opróżniania (flush-agents) na instancjach autorskich lub publikujących. Zalecamy użycie agenta opróżniania na instancji publikującej w celu uzyskania bardziej niezawodnego automatycznego unieważniania, ponieważ użycie agenta opróżniania na instancji autorskiej może prowadzić do następujących problemów:
- Dispatcher musi być dostępny dla serwera AEM instancji autorskiej. Jeśli Twoja sieć (np. z powodu zapory ogniowej) jest skonfigurowana w taki sposób, że dostęp między nimi jest zabroniony, automatyczne unieważnianie nie zadziała.
- Publikowanie i unieważnianie pamięci podręcznej odbywają się jednocześnie. Użytkownik może zażądać strony natychmiast po usunięciu jej z pamięci podręcznej, ale zanim strona zostanie opublikowana. W tej sytuacji AEM zwraca starą stronę, a dispatcher ponownie ją buforuje i uznaje za teraz ważną. Ten problem dotyczy głównie dużych witryn.
Agent opróżniania na instancji publikującej znajduje się pod adresem: http://localhost:4503/etc/replication/agents.publish/flush.html
Aby włączyć agenta opróżniania na instancji publikującej, kliknij przycisk “Edytuj” i zaznacz pole wyboru “Włączone”:
Zaktualizuj port URI w zakładce Transport i ustaw jego wartość na 80:
Zapisz swoje zmiany, a zobaczysz, że agent opróżniania na instancji publikującej został aktywowany:
Ręczne żądania unieważnienia
Możesz wysłać następujące żądania, aby ręcznie unieważnić zasoby w pamięci podręcznej:
- aby usunąć pliki z pamięci podręcznej
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0
- aby usunąć i ponownie zapisać pliki w pamięci podręcznej
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
Content-Type: text/plain
CQ-Handle: path-pattern
Content-Length: numchars in bodypage_path0
Page_path1
…
Page_pathn
Podsumowanie
W rezultacie udało nam się dowiedzieć, jak działają następujące elementy:
- Niskopoziomowy mechanizm unieważniania;
- Agenty opróżniania do automatycznego unieważniania po opublikowaniu stron;
- Ręczne zapytania o unieważnienie.
Bardziej szczegółowa i przydatna dokumentacja dostępna jest na następujących stronach:
http://docs.adobe.com/docs/en/dispatcher/disp-config.html
http://docs.adobe.com/docs/en/dispatcher/page-invalidate.html
FAQ
Jak wyczyścić pamięć podręczną Dispatchera w AEM?
Istnieją co najmniej 3 sposoby na wyczyszczenie pamięci podręcznej Dispatchera w AEM:
- Za pomocą agentów opróżniania na instancjach autorskich i/lub publikujących
- Ręczne opróżnianie
- Niestandardowy kod do programowego opróżniania
Czym jest pamięć podręczna Dispatchera w AEM?
Dispatcher to narzędzie AEM do buforowania i równoważenia obciążenia, które przechowuje buforowane pliki na serwerze WWW w taki sam sposób, jak statyczna witryna internetowa.
Jak sprawdzić logi Dispatchera w AEM?
Logi Dispatchera są kontrolowane w konfiguracji modułu Dispatchera. W zależności od konfiguracji, może to być oddzielny plik .conf w /etc/httpd/conf.d lub w tym samym pliku co konfiguracja vhosta Dispatchera.
Jaka jest różnica między opróżnianiem (cache flush) a unieważnianiem (invalidate) pamięci podręcznej w AEM?
Zgodnie z dokumentacją, zarówno opróżnianie (flush), jak i unieważnianie (invalidation) oznaczają to samo.
„Aby unieważnić (lub opróżnić) pamięć podręczną Dispatchera bez aktywowania strony, można wysłać żądanie HTTP do Dispatchera.”
Ale można śmiało powiedzieć, że unieważnianie (invalidation) to wywołanie HTTP do Dispatchera w celu oznaczenia zasobu w pamięci podręcznej jako nieprawidłowego (to samo dzieje się, gdy wygaśnie TTL zasobu). Natomiast opróżnianie (flush) zazwyczaj oznacza unieważnienie wywołane z instancji Author/Publish po opublikowaniu treści.
