Zobacz również:
Buforowanie (caching) jest kluczowym czynnikiem wpływającym na wydajność i źródłem problemów, gdy nie jest prawidłowo skonfigurowane. Ten artykuł przedstawi przegląd oraz przydatne, praktyczne szczegóły dotyczące dostosowywania buforowania dla lokalnego środowiska deweloperskiego i miejsca przechowywania buforowanych plików.
Czym więc jest pamięć podręczna (cache) w AEM i jak działa?
Pamięć podręczna (cache) w AEM to komponent, który w sposób przezroczysty przechowuje dane, aby przyszłe żądania tych danych mogły być obsłużone szybciej. Po otrzymaniu żądania, dokument podlegający buforowaniu jest sprawdzany przez Dispatcher w celu ustalenia, czy ten dokument istnieje w systemie plików serwera WWW:
- Jeśli dokument jest buforowany, Dispatcher zwraca plik.
- Dispatcher żąda dokumentu z instancji AEM, jeśli nie jest on buforowany.
Domyślnie zasoby będą buforowane tylko wtedy, gdy spełnione są wszystkie poniższe warunki:
- Żądanie HTTP używa metody GET;
- Żądany URL ma rozszerzenie (takie jak .html lub .xml);
- Żądany URL nie ma ciągu zapytania (po rozszerzeniu nie ma parametrów);
- Żądanie nie ma nagłówka „Authorization” (chyba że AllowAuthorized wynosi 1).
Ustawienia są zdefiniowane w pliku konfiguracyjnym dispatchera. W naszym przypadku jest to plik conf/dispatcher.any. Plik konfiguracyjny zawiera serię właściwości jedno- lub wielowartościowych, które kontrolują zachowanie dispatchera:
- nazwy właściwości są poprzedzone ukośnikiem („/”);
- właściwości wielowartościowe zawierają elementy podrzędne w nawiasach klamrowych („{}”);
- komentarze zaczynają się od symbolu „#”.
Renderery
Najpierw należy określić renderery dla dispatchera. Renderery to instancje AEM, z których dispatcher pobiera treści, które mogą być buforowane. Renderery to pierwsza rzecz, którą zdefiniujemy w naszym pliku konfiguracyjnym. Dispatcher automatycznie zrównoważy obciążenie między tymi instancjami AEM, jeśli zdefiniujesz więcej niż jeden renderer. W naszym przypadku ustawimy tylko jeden renderer: publiczną instancję AEM.
/renders
{
/rend01
{
/hostname "localhost"
/port "4503"
}
}
Możesz teraz ponownie uruchomić httpd serwer i sprawdzić, czy dispatcher może żądać zasobów z publicznej instancji AEM.
Na przykład, jeśli masz działającą http://localhost:4503/content/geometrixx/en.html stronę, wówczas wersja tej strony obsługiwana przez dispatcher powinna być dostępna pod adresem http://localhost/content/geometrixx/en.html. Zauważ, że nie ustawiamy portu w żądaniu URL, ponieważ dispatcher (dokładniej, httpd) działa na porcie 80, który jest domyślny dla wszystkich przeglądarek.
Filtry
Sekcja /filter określa żądania HTTP, które dispatcher może akceptować. Wszystkie inne żądania są odsyłane do serwera WWW z kodem błędu 404 (strona nie znaleziona). Pozwólmy na dostęp do wszystkich zasobów dla naszego przypadku demonstracyjnego.
/filter
{
/0001 { /type "allow" /glob "*" }
}
Typy filtrów: “allow” lub “deny”.
Globy będą porównywane z całą linią żądania, np.:
/0001 { /type "allow" /glob "* /index.html *" }
Ten glob pasuje do żądania “GET /index.html HTTP/1.1”, ale nie do “GET /index.html?a=b HTTP/1.1”.
Zamiast “globs”, możesz użyć osobnych “url”, “method”, “protocol”, “extension” do zdefiniowania filtra. Oprócz “url”, możesz użyć “path”, “selectors”, “extension”, “suffix”.
Gdy żądanie pasuje do wielu wzorców filtrów, stosowany jest tylko ostatni wzorzec filtra.
Po zdefiniowaniu filtrów, możesz ponownie uruchomić httpd i sprawdzić, czy dispatcher ma dostęp do wszystkich zasobów publicznej instancji AEM. Oczywiście, w rzeczywistym środowisku produkcyjnym powinieneś odmówić dostępu do niektórych zasobów ze względów bezpieczeństwa.
Pamięć podręczna
Sekcja pamięci podręcznej określa zasoby, które dispatcher będzie buforować. Ta sekcja ma wiele reguł podobnych do reguł filtrów, z kilkoma dodatkowymi ustawieniami.
Na przykład, /docroot określa lokalizację katalogu, gdzie przechowywane są pliki w pamięci podręcznej. Wartość musi być dokładnie taką samą ścieżką jak katalog główny dokumentów serwera WWW, aby dispatcher i serwer WWW mogły obsługiwać te same pliki.
Dla naszej demonstracji, ustawmy docroot i zezwólmy na buforowanie wszystkich zasobów otrzymanych z naszego renderera (instancji publikującej):
/cache
{
/docroot "/Apache22/htdocs"
/rules
{
/0000
{
/glob "*"
/type "allow"
}
}
}
Po zastosowaniu tych zmian, możesz ponownie uruchomić serwer HTTPd, otworzyć nowe prywatne okno przeglądarki dla nieautoryzowanego dostępu bez użycia nagłówka „Authorization” (Chrome ctrl+shift+n, Firefox ctrl+shift+p) i przejść do: http://localhost/content/geometrixx/en/products.html.
Zbuforowane zasoby powinny pojawić się w katalogu htdocs. Zasoby mają hierarchię podobną do URL: katalogi tworzą ścieżki, a statyczne pliki HTML zawierają wyrenderowaną zawartość.
Nagłówki
Wiesz, że zbuforowane pliki HTML zawierają tylko zawartość HTML. Ale co zrobić, jeśli chcemy buforować nagłówki odpowiedzi otrzymane z rendererów?
Na przykład, jeśli odpowiedzi z rendererów zawierają nagłówek „Content-Type”, który definiuje kodowanie, zawartość HTML może nie być wyświetlana poprawnie bez tego nagłówka. Do tego właśnie służy blok /headers w sekcjach /cache. Zbuforujmy kilka typowych i użytecznych nagłówków:
/cache
{
/headers
{
"Cache-Control"
"Content-Disposition"
"Content-Type"
"Expires"
"Last-Modified"
"X-Content-Type-Options"
}
}
Po zmianie nagłówków w pliku konfiguracyjnym Dispatchera, usuń całą pamięć podręczną z katalogu htdocs i ponownie uruchom httpd. Następnie możesz otworzyć http://localhost/content/geometrixx/en/products.html.
Na koniec, znajdziesz nie tylko zbuforowany plik HTML products.html w katalogu htdocs/content/geometrixx/en, ale także plik products.html.h obok oryginalnego pliku HTML products.html. Ten plik *.h zawiera nagłówki dla zbuforowanego pliku HTML.
Podsumowanie
Możesz szybko aktywować buforowanie, używając następujących początkowych ustawień w pliku konfiguracyjnym Dispatchera:
- ustaw renderery;
- ustaw filtry;
- ustaw htdocs i zasady dla sekcji buforowania;
- ustaw nagłówki do przechowywania nagłówków HTTP.
FAQ
Jak działa pamięć podręczna Dispatchera AEM?
Po żądaniu, dokument podlegający buforowaniu jest sprawdzany przez Dispatchera, aby ustalić, czy ten dokument istnieje w systemie plików serwera www:
Jeśli dokument jest buforowany, Dispatcher zwraca plik. Jeśli dokument nie jest buforowany, Dispatcher żąda go z instancji AEM.
Czym jest pamięć podręczna w AEM?
Pamięć podręczna w AEM to komponent, który w sposób przezroczysty przechowuje dane, aby przyszłe żądania tych danych mogły być obsługiwane szybciej.
Czym jest buforowanie uwzględniające uprawnienia w AEM?
Buforowanie uwzględniające uprawnienia w AEM umożliwia buforowanie zabezpieczonych stron. Dispatcher sprawdza uprawnienia dostępu użytkownika do strony przed dostarczeniem strony z pamięci podręcznej.
