Jak skonfigurować buforowanie treści Apache na Ubuntu 14.04

Co to jest buforowanie?

Buforowanie jest metodą poprawy wydajności serwera poprzez umożliwienie często żądanej zawartości do tymczasowego przechowywania w sposób, który pozwala na szybszy dostęp. Przyspiesza to przetwarzanie i dostarczanie poprzez eliminację niektórych operacji pochłaniających zasoby.

Tworząc skuteczne reguły buforowania, zawartość, która nadaje się do buforowania, będzie przechowywana w celu poprawy czasów odpowiedzi, zachowania zasobów i zminimalizowania obciążenia. Apache udostępnia wiele różnych cache’ów odpowiednich do przyspieszenia różnych typów operacji. W tym przewodniku omówimy, jak skonfigurować Apache 2.4 na Ubuntu 14.04 przy użyciu różnych modułów buforujących.

Aby dowiedzieć się więcej o tworzeniu ogólnych strategii buforowania, sprawdź ten artykuł.

Wprowadzenie do buforowania w Apache

Apache może buforować zawartość o różnym poziomie zaawansowania i skalowalności. Projekt dzieli je na trzy grupy w zależności od metody, w jaki sposób zawartość jest buforowana. Ogólny podział jest następujący:

• Buforowanie plików: Najbardziej podstawowa strategia buforowania, to po prostu otwieranie plików lub deskryptorów plików, gdy serwer startuje i utrzymywanie ich dostępnych w celu przyspieszenia dostępu.
• Buforowanie klucz-wartość: Głównie używane do buforowania SSL i uwierzytelniania, buforowanie klucz-wartość używa modelu obiektu współdzielonego, który może przechowywać elementy, które są kosztowne do wielokrotnego obliczania.
• Standardowe buforowanie HTTP: Najbardziej elastyczny i ogólnie użyteczny mechanizm buforowania, ten trójstanowy system może przechowywać odpowiedzi i zatwierdzać je, gdy wygasają. Można go skonfigurować pod kątem wydajności lub elastyczności w zależności od konkretnych potrzeb.

Szybkie spojrzenie na powyższe opisy może ujawnić, że powyższe metody w pewnym stopniu się pokrywają, ale także, że pomocne może być użycie więcej niż jednej strategii w tym samym czasie. Na przykład, użycie magazynu wartości kluczowych dla sesji SSL i włączenie standardowej pamięci podręcznej HTTP dla odpowiedzi może pozwolić na znaczne odciążenie źródeł danych i przyspieszenie wielu operacji dostarczania treści dla klientów.

Teraz, gdy masz już szerokie zrozumienie każdego z mechanizmów buforowania Apache’a, przyjrzyjmy się tym systemom bardziej szczegółowo.

Buforowanie plików

Ogólny przegląd

• Podstawowe moduły biorące udział w tym procesie: mod_file_cache
• Główne przypadki użycia: przechowywanie zawartości plików lub deskryptorów plików przy starcie serwera. Są to statyczne reprezentacje, które nie mogą być wiarygodnie zmienione do czasu ponownego uruchomienia serwera.
• Cechy: proste, poprawia wydajność powolnych systemów plików
• Wady: funkcja eksperymentalna, nie reaguje na aktualizacje systemu plików, musi być używana oszczędnie, aby zmieścić się w ograniczeniach systemu operacyjnego, może być używana tylko na statycznych plikach

Szczegóły

Moduł mod_file_cache jest głównie używany do przyspieszenia dostępu do plików na serwerach z powolnymi systemami plików. Zapewnia on wybór dwóch dyrektyw konfiguracyjnych, z których obie mają na celu przyspieszenie procesu serwowania plików statycznych przez wykonanie części pracy w momencie uruchomienia serwera, a nie w momencie żądania plików.

Dyrektywa CacheFile służy do określenia ścieżki do plików na dysku, do których chciałbyś przyspieszyć dostęp. Kiedy Apache jest uruchamiany, Apache otwiera statyczne pliki, które zostały określone i buforuje uchwyt pliku, unikając potrzeby otwierania pliku, gdy jest on żądany. Liczba plików, które można otworzyć w ten sposób, podlega ograniczeniom ustalonym przez twój system operacyjny.

Dyrektywa MMapFile również otwiera pliki przy pierwszym uruchomieniu Apache. Jednak MMapFile buforuje zawartość pliku w pamięci, a nie tylko jego obsługę. Pozwala to na szybszą wydajność dla tych stron, ale ma pewne poważne ograniczenia. Nie przechowuje żadnych informacji o ilości wykorzystanej pamięci, więc możliwe jest jej wyczerpanie. Należy również pamiętać, że procesy potomne będą kopiować każdą z przydzielonych pamięci, co może spowodować szybsze wyczerpanie zasobów niż początkowo można się spodziewać. Używaj tej dyrektywy oszczędnie.

Te dyrektywy są analizowane tylko przy starcie Apache. Oznacza to, że nie można liczyć na to, że Apache wychwyci zmiany dokonane po jego starcie. Używaj ich tylko dla plików statycznych, które nie zmienią się przez cały czas trwania sesji Apache. W zależności od tego jak pliki są modyfikowane, serwer może zostać powiadomiony o zmianach, ale nie jest to oczekiwane zachowanie i nie zawsze będzie działać poprawnie. Jeśli zmiany muszą być dokonane w plikach przekazywanych do tych dyrektyw, zrestartuj Apache po dokonaniu zmian.

How To Enable File Caching

Buforowanie plików jest zapewniane przez moduł mod_file_cache. Aby korzystać z tej funkcjonalności, musisz włączyć moduł.

Podczas pracy w Ubuntu 14.04, moduł będzie zainstalowany, ale wyłączony podczas instalacji Apache. Możesz włączyć moduł wpisując:

sudo a2enmod file_cache

Potem, powinieneś edytować główny plik konfiguracyjny, aby ustawić dyrektywy buforowania plików. Otwórz plik wpisując:

sudo nano /etc/apache2/apache2.conf

Aby skonfigurować buforowanie uchwytów plików, użyj dyrektywy CacheFile. Dyrektywa ta przyjmuje listę ścieżek do plików, oddzielonych spacjami, jak poniżej:

CacheFile /var/www/html/index.html /var/www/html/somefile.index

Po ponownym uruchomieniu serwera Apache otworzy wymienione pliki i przechowa ich uchwyty w pamięci podręcznej dla szybszego dostępu.

Jeśli zamiast tego chcesz zmapować kilka plików bezpośrednio do pamięci, możesz użyć dyrektywy MMapFile. Jej składnia jest w zasadzie taka sama jak ostatniej dyrektywy, w tym sensie, że po prostu przyjmuje listę ścieżek do plików:

MMapFile /var/www/html/index.html /var/www/html/somefile.index

W praktyce nie ma powodu, aby konfigurować zarówno CacheFile jak i MMapFile dla tego samego zestawu plików, ale można użyć obu dla różnych zestawów plików.

Kiedy skończysz, możesz zapisać i zamknąć pliki. Sprawdź składnię pliku konfiguracyjnego, wpisując:

sudo apachectl configtest

Jeśli ostatnia linia brzmi Syntax OK, możesz bezpiecznie zrestartować swoją instancję Apache:

sudo service apache2 restart

Apache uruchomi się ponownie, buforując zawartość plików lub handlerów, w zależności od dyrektyw, których użyłeś.

Key-Value Caching

General Overview

• Podstawowe moduły biorące udział w projekcie: mod_socache_dbm, mod_socache_dc, mod_socache_memcache, mod_socache_shmcb
• Zaangażowane moduły wspierające: mod_authn_socache, mod_ssl
• Główne przypadki użycia: przechowywanie sesji SSL lub szczegółów uwierzytelniania, zszywanie SSL
• Cechy: shared object cache do przechowywania złożonych zasobów, może pomagać w buforowaniu i zszywaniu sesji SSL, elastyczne backendy
• Wady: nie posiada mechanizmów walidacji, konieczność skonfigurowania osobnego oprogramowania dla bardziej wydajnych/elastycznych backendów, pewne błędy w kodzie

Szczegóły

Buforowanie wartości klucza jest bardziej złożone niż buforowanie plików i ma bardziej ukierunkowane korzyści. Znane również jako współdzielone buforowanie obiektów, buforowanie klucz-wartość Apache’a jest głównie używane do uniknięcia powtarzania kosztownych operacji związanych z ustawianiem dostępu klienta do treści, w przeciwieństwie do samej treści. W szczególności, może być używany do buforowania szczegółów uwierzytelniania, sesji SSL, oraz do zapewnienia zszywania SSL.

Obecnie istnieją pewne problemy z każdym dostawcą pamięci podręcznej obiektów współdzielonych. Odniesienia do tych problemów zostaną przedstawione poniżej. Weź je pod uwagę przy ocenie, czy włączyć tę funkcję.

Faktyczne buforowanie jest realizowane poprzez użycie jednego z modułów dostawcy buforowania obiektów współdzielonych. Są to:

• mod_socache_dbm: Ten backend używa prostego dbm silnika bazy danych, który jest opartym na pliku magazynem wartości kluczowych, który wykorzystuje haszowanie i wiadra o stałym rozmiarze. Ten dostawca cierpi na pewne wycieki pamięci, więc w większości przypadków zaleca się używanie mod_socache_shmcb zamiast tego.
• mod_socache_dc: Ten dostawca używa oprogramowania buforowania sesji distcache. Ten projekt nie był aktualizowany od 2004 roku i nie jest nawet spakowany dla niektórych dystrybucji, więc używaj ze zdrową dawką ostrożności.
• mod_socache_memcache: To używa pamięci podręcznej obiektów pamięci rozproszonej memcache do przechowywania elementów. Jest to najlepsza opcja dla rozproszonej pamięci podręcznej pomiędzy wieloma serwerami. Obecnie nie wygasza on poprawnie wpisów, ale do trunk’a kontroli wersji Apache’a została dodana poprawka, która naprawia ten problem.
• mod_socache_shmcb: Obecnie jest to najlepsza opcja dla buforowania klucz-wartość. To buforuje do cyklicznego bufora w pamięci współdzielonej, który będzie usuwał wpisy, gdy się zapełni. Obecnie dławi się przy wpisach powyżej 11k w rozmiarze.

Wraz z powyższymi modułami dostawcy, dodatkowe moduły będą wymagane w zależności od buforowanych obiektów. Na przykład, aby buforować sesje SSL lub skonfigurować zszywanie SSL, mod_ssl musi być włączone, co zapewni odpowiednio dyrektywy SSLSessionCache i SSLStaplingCache. Podobnie, aby skonfigurować buforowanie uwierzytelniania, moduł mod_authn_socache musi być włączony, aby można było ustawić dyrektywę AuthnCacheSOCache.

How To Enable Key-Value Caching

Pamiętając o powyższych błędach i zastrzeżeniach, jeśli nadal chcesz skonfigurować ten typ buforowania w Apache, postępuj zgodnie z poniższymi wskazówkami.

Metoda użyta do skonfigurowania pamięci podręcznej key-value będzie zależała od tego, do czego będzie używana i jakiego dostawcy używasz. Poniżej omówimy podstawy buforowania uwierzytelniania i sesji SSL.

Obecnie istnieje błąd z buforowaniem uwierzytelniania, który uniemożliwia przekazywanie argumentów do dostawcy pamięci podręcznej. Tak więc każdy dostawca, który nie zapewnia domyślnych ustawień, na których można się oprzeć, będzie miał problemy.

Buforowanie uwierzytelniania

Buforowanie uwierzytelniania jest przydatne, jeśli używasz kosztownej metody uwierzytelniania, takiej jak LDAP lub uwierzytelnianie baz danych. Tego typu operacje mogą mieć znaczący wpływ na wydajność, jeśli backend musi być uderzany za każdym razem, gdy wykonywane jest żądanie uwierzytelnienia.

Ustawienie buforowania wymaga modyfikacji istniejącej konfiguracji uwierzytelniania (nie będziemy zajmować się tym, jak skonfigurować uwierzytelnianie w tym przewodniku). Same modyfikacje będą takie same, niezależnie od metody uwierzytelniania backendu. My użyjemy mod_socache_shmcb do naszej demonstracji.

Po pierwsze, włącz moduł authn_socache i moduł dostawcy mod_socache_shmcb, wpisując:

 
sudo a2enmod authn_socache
 
sudo a2enmod socache_shmcb
 

Otwórz główny plik konfiguracyjny Apache’a, tak abyś mógł określić ten współdzielony backend cache do użycia z uwierzytelnianiem:

sudo nano /etc/apache2/apache2.conf

Wewnątrz, na górze pliku, dodaj dyrektywę AuthnCacheSOCache. Określ, że shmcb powinien być użyty jako dostawca. Jeśli omawiany wcześniej błąd uniemożliwiający przekazywanie opcji zostanie naprawiony do czasu, gdy będziesz to czytał, będziesz mógł określić lokalizację i rozmiar pamięci podręcznej. Liczba jest podawana w bajtach, więc skomentowany przykład da w rezultacie 512 kilobajtową pamięć podręczną:

AuthnCacheSOCache shmcb# If the bug preventing passed arguments to the provider gets fixed,# you can customize the location and size like this#AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)

Zapisz i zamknij plik, gdy skończysz.

Następnie otwórz stronę konfiguracyjną swojego hosta wirtualnego, który ma skonfigurowane uwierzytelnianie. Zakładamy, że używasz konfiguracji 000-default.conf wirtualnego hosta, ale powinieneś ją zmodyfikować, aby odzwierciedlała twoje środowisko:

sudo nano /etc/apache2/sites-enabled/000-default.conf

W miejscu, w którym skonfigurowałeś uwierzytelnianie, zmodyfikuj blok, aby dodać buforowanie. Konkretnie, musisz dodać AuthnCacheProvideFor, aby powiedzieć, które źródła uwierzytelniania mają być buforowane, dodać limit czasu buforowania z AuthnCacheTimeout i dodać socache do listy AuthBasicProvider przed konwencjonalną metodą uwierzytelniania. Rezultaty będą wyglądać tak:

<VirtualHost *:80> . . . <Directory /var/www/html/private> AuthType Basic AuthName "Restricted Files" AuthBasicProvider socache file AuthUserFile /etc/apache2/.htpasswd AuthnCacheProvideFor file AuthnCacheTimeout 300 Require valid-user </Directory></VirtualHost>

Powyższy przykład dotyczy uwierzytelniania plików, które prawdopodobnie nie skorzysta zbytnio z buforowania. Jednakże, implikacja powinna być bardzo podobna przy użyciu innych metod uwierzytelniania. Jedyna istotna różnica polega na tym, że tam gdzie w powyższym przykładzie znajduje się specyfikacja „plik”, użyta zostanie inna metoda uwierzytelniania.

Zapisz i zamknij plik. Zrestartuj Apache, aby wdrożyć zmiany w buforowaniu:

sudo service apache2 restart

Buforowanie sesji SSL

Uchwyt, który musi być wykonany, aby ustanowić połączenie SSL, niesie ze sobą znaczny narzut. W związku z tym, buforowanie danych sesji w celu uniknięcia tego kroku inicjalizacji dla kolejnych żądań może potencjalnie pominąć tę karę. The shared object cache is a perfect place for this.

Jeśli masz SSL już skonfigurowany dla swojego serwera Apache, mod_ssl będzie włączone. Na Ubuntu oznacza to, że plik ssl.conf został przeniesiony do katalogu /etc/apache2/mods-enabled. To właściwie już ustawia buforowanie. Wewnątrz, zobaczysz kilka linii takich jak:

. . .SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)SSLSessionCacheTimeout 300. . .

To właściwie wystarczy, aby ustawić buforowanie sesji. Aby to przetestować, możesz użyć klienta połączenia OpenSSL. Wpisz:

openssl s_client -connect 127.0.0.1:443 -reconnect -no_ticket | grep Session-ID

Jeśli identyfikator sesji jest taki sam we wszystkich wynikach, twoja pamięć podręczna sesji działa poprawnie. Naciśnij CTRL-C, aby wyjść z powrotem do terminala.

Standardowe buforowanie HTTP

Przegląd ogólny

• Podstawowe zaangażowane moduły: mod_cache
• Zaangażowane moduły wspierające: mod_cache_disk, mod_cache_socache
• Główne przypadki użycia: Buforowanie ogólnej zawartości
• Cechy: Może poprawnie interpretować nagłówki buforowania HTTP, może rewalidować nieświeże wpisy, może być wdrożony dla maksymalnej prędkości lub elastyczności w zależności od potrzeb
• Wady: Może wyciekać wrażliwe dane, jeśli jest źle skonfigurowany, musi używać dodatkowych modułów, aby poprawnie ustawić politykę buforowania

Szczegóły

Protokół HTTP zachęca i zapewnia mechanizmy buforowania odpowiedzi na całej ścieżce dostarczania treści. Każdy komputer, który dotyka treści, może potencjalnie buforować każdy element przez pewien czas w zależności od zasad buforowania określonych w źródłach treści i własnych zasad buforowania komputera.

Mechanizm buforowania HTTP Apache buforuje odpowiedzi zgodnie z zasadami buforowania HTTP, które widzi. Jest to system buforowania ogólnego przeznaczenia, który przestrzega tych samych zasad, które przestrzegałby każdy serwer pośredniczący, który ma udział w dostarczaniu. To czyni ten system bardzo elastycznym i potężnym i pozwala na wykorzystanie nagłówków, które już powinieneś ustawić na swojej zawartości (zajmiemy się tym poniżej).

Pamięć podręczna HTTP Apache’a jest również znana jako „trójstanowa” pamięć podręczna. Dzieje się tak, ponieważ zawartość, którą przechowuje może być w jednym z trzech stanów. Może być świeża, co oznacza, że może być serwowana klientom bez dalszego sprawdzania, może być nieaktualna, co oznacza, że TTL na zawartości wygasł, lub może być nieistniejąca, jeśli zawartość nie została znaleziona w pamięci podręcznej.

Jeśli zawartość staje się nieaktualna, przy następnym żądaniu, pamięć podręczna może ją ponownie zatwierdzić poprzez sprawdzenie zawartości w miejscu pochodzenia. Jeśli się nie zmieniła, może zresetować datę świeżości i służyć aktualnej zawartości. W przeciwnym razie pobiera zmienioną zawartość i przechowuje ją przez czas dozwolony przez politykę buforowania.

Przegląd modułów

Logika buforowania HTTP jest dostępna przez moduł mod_cache. Rzeczywiste buforowanie jest wykonywane za pomocą jednego z dostawców buforowania. Zazwyczaj pamięć podręczna jest przechowywana na dysku za pomocą modułu mod_cache_disk, ale buforowanie obiektów współdzielonych jest również dostępne za pomocą modułu mod_cache_socache.

Moduł mod_cache_disk buforuje na dysku, więc może być przydatny, jeśli prokserujesz zawartość ze zdalnej lokalizacji, generujesz ją z dynamicznego procesu lub po prostu próbujesz przyspieszyć rzeczy przez buforowanie na szybszym dysku niż typowa zawartość. Jest to najlepiej przetestowany dostawca i prawdopodobnie powinien być Twoim pierwszym wyborem w większości przypadków. Pamięć podręczna nie jest czyszczona automatycznie, więc narzędzie o nazwie htcacheclean musi być uruchamiane od czasu do czasu, aby odchudzić pamięć podręczną. Można je uruchomić ręcznie, skonfigurować jako zwykłe zadanie cron lub uruchomić jako demona.

Moduł mod_cache_socache buforuje do jednego z dostawców obiektów współdzielonych (tych samych, które omówiono w ostatniej sekcji). To może potencjalnie mieć lepszą wydajność niż mod_cache_disk (w zależności od tego, który dostawca współdzielonej pamięci podręcznej jest wybrany). Jednak jest on znacznie nowszy i opiera się na dostawcach obiektów współdzielonych, które mają błędy omówione wcześniej. Zalecane jest przeprowadzenie kompleksowych testów przed wdrożeniem opcji mod_cache_socache.

Umieszczenie pamięci podręcznej HTTP

Pamięć podręczna HTTP może być wdrożona w dwóch różnych konfiguracjach w zależności od potrzeb.

Jeśli CacheQuickHandler jest ustawione na „on”, pamięć podręczna będzie sprawdzana bardzo wcześnie w procesie obsługi żądania. Jeśli zawartość zostanie znaleziona, zostanie ona obsłużona bezpośrednio bez dalszej obsługi. Oznacza to, że jest to niewiarygodnie szybkie, ale oznacza to również, że nie pozwala na procesy takie jak uwierzytelnianie dla zawartości. Jeśli w twojej pamięci podręcznej znajduje się zawartość, która normalnie wymaga uwierzytelnienia lub kontroli dostępu, będzie ona dostępna dla każdego bez uwierzytelnienia, jeśli CacheQuickHandler jest ustawione na „on”.

Podstawowo, emuluje to oddzielną pamięć podręczną przed twoim serwerem WWW. Jeśli twój serwer WWW musi wykonywać jakiekolwiek sprawdzanie warunkowe, uwierzytelnianie lub autoryzację, nie będzie to miało miejsca. Apache nie będzie nawet oceniał dyrektyw wewnątrz bloków <Location> lub <Directory>. Zauważ, że CacheQuickHandler jest domyślnie ustawiony na „włączony”!

Jeśli CacheQuickHandler jest ustawiony na „wyłączony”, cache będzie sprawdzany znacznie później w sekwencji przetwarzania żądania. Pomyśl o tej konfiguracji jako o umieszczeniu pamięci podręcznej między logiką przetwarzania Apache a rzeczywistą zawartością. Pozwoli to na uruchomienie konwencjonalnych dyrektyw przetwarzania przed pobraniem zawartości z pamięci podręcznej. Ustawienie tego na „off” przehandluje trochę prędkości za możliwość głębszego przetwarzania żądań.

How To Configure Standard HTTP Caching

Aby włączyć buforowanie, będziesz musiał włączyć moduł mod_cache, jak również jednego z jego dostawców buforowania. Jak stwierdziliśmy powyżej, mod_cache_disk jest dobrze przetestowany, więc będziemy na nim polegać.

Włączanie modułów

W systemie Ubuntu możesz włączyć te moduły, wpisując:

 
sudo a2enmod cache
 
sudo a2enmod cache_disk
 

To włączy funkcjonalność buforowania przy następnym ponownym uruchomieniu serwera.

Będziesz także potrzebował zainstalować pakiet apache2-utils, który zawiera narzędzie htcacheclean używane do zmniejszania pamięci podręcznej, gdy jest to konieczne. Możesz go zainstalować, wpisując:

 
sudo apt-get update
 
sudo apt-get install apache2-utils
 

Modyfikowanie konfiguracji globalnej

Większość konfiguracji buforowania będzie miała miejsce w indywidualnych definicjach hostów wirtualnych lub blokach lokalizacji. Jednakże, włączenie mod_cache_disk umożliwia również globalną konfigurację, która może być użyta do określenia pewnych ogólnych atrybutów. Otwórz teraz ten plik, aby rzucić okiem:

sudo nano /etc/apache2/mods-enabled/cache_disk.conf

Po usunięciu komentarzy plik powinien wyglądać tak:

<IfModule mod_cache_disk.c> CacheRoot /var/cache/apache2/mod_cache_disk CacheDirLevels 2 CacheDirLength 1</IfModule>

Owijka IfModule mówi Apache’owi, aby przejmował się tymi dyrektywami tylko wtedy, gdy moduł mod_cache_disk jest włączony. Dyrektywa CacheRoot określa miejsce na dysku, gdzie będzie utrzymywany cache. Dyrektywy CacheDirLevels i CacheDirLength przyczyniają się do określenia, w jaki sposób zostanie zbudowana struktura katalogów pamięci podręcznej.

Jako klucz do przechowywania danych zostanie utworzony md5 hash obsługiwanego adresu URL. Dane będą zorganizowane w katalogach pochodzących z początkowych znaków każdego hasha. CacheDirLevels określa liczbę podkatalogów do utworzenia, a CacheDirLength określa, ile znaków użyć w nazwie każdego katalogu. Tak więc hash o wartości b1946ac92492d2347c6235b4d2611184 z wartościami domyślnymi pokazanymi powyżej zostanie zapisany w strukturze katalogów b/1/946ac92492d2347c6235b4d2611184. Zazwyczaj nie będziesz musiał modyfikować tych wartości, ale dobrze jest wiedzieć, do czego są używane.

Jeśli zdecydujesz się zmodyfikować wartośćCacheRoot, będziesz musiał otworzyć plik/etc/default/apache2i zmodyfikować wartośćHTCACHECLEAN_PATH, aby odpowiadała twojemu wyborowi. Jest to używane do czyszczenia pamięci podręcznej w regularnych odstępach czasu, więc musi mieć prawidłową lokalizację pamięci podręcznej.

Kilka innych wartości, które można ustawić w tym pliku to CacheMaxFileSize i CacheMinFileSize, które ustawiają zakresy rozmiarów plików w bajtach, które Apache będzie przekazywał do pamięci podręcznej, a także CacheReadSize i CacheReadTime, które pozwalają czekać i buforować zawartość przed wysłaniem do klienta. Może to być przydatne, jeśli zawartość znajduje się gdzieś indziej niż na tym serwerze.

Modyfikowanie serwera wirtualnego

Większość konfiguracji buforowania odbywa się na bardziej szczegółowym poziomie, albo w definicji hosta wirtualnego, albo w bloku konkretnej lokalizacji.

Otwórz jeden z plików hosta wirtualnego, aby podążać za nim. Zakładamy, że używasz domyślnego pliku w tym przewodniku:

sudo nano /etc/apache2/sites-enabled

W bloku wirtualnego hosta, poza jakimkolwiek blokiem lokalizacji, możemy zacząć konfigurować niektóre z właściwości buforowania. W tym przewodniku założymy, że chcemy wyłączyć CacheQuickHandler, aby więcej przetwarzania zostało wykonane. To pozwoli nam na stworzenie bardziej kompletnych reguł buforowania.

Przy tej okazji skonfigurujemy również blokowanie pamięci podręcznej. Jest to system blokad plików, których Apache będzie używał gdy będzie sprawdzał czy zawartość jest nadal ważna. W czasie, gdy to zapytanie jest zaspokajane, jeśli przyjdą dodatkowe żądania dla tej samej treści, spowoduje to dodatkowe żądania do zasobów backendu, co może spowodować skoki obciążenia.

Ustawienie blokady pamięci podręcznej dla zasobu podczas walidacji mówi Apache’owi, że zasób jest obecnie odświeżany. W tym czasie, nieświeży zasób może być serwowany z nagłówkiem ostrzegawczym wskazującym jego stan. Ustawimy to za pomocą katalogu cache lock w folderze /tmp. Pozwolimy na maksymalnie 5 sekund, aby blokada została uznana za ważną. Te przykłady są wzięte bezpośrednio z dokumentacji Apache’a, więc powinny działać dobrze dla naszych celów.

Powiemy również Apache’owi, aby ignorował nagłówki Set-Cookie i nie przechowywał ich w pamięci podręcznej. Zapobiegnie to przypadkowemu wyciekowi ciasteczek specyficznych dla użytkownika do innych stron. Nagłówek Set-Cookie zostanie usunięty zanim nagłówki zostaną zbuforowane.

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie</VirtualHost>

Wciąż musimy włączyć buforowanie dla tego wirtualnego hosta. Możemy to zrobić za pomocą dyrektywy CacheEnable. Jeśli jest ona ustawiona w bloku wirtualnego hosta, będziemy musieli podać metodę buforowania (disk lub socache), jak również żądane URI, które powinny być buforowane. Na przykład, aby buforować wszystkie odpowiedzi, może to być ustawione na CacheEnable disk /, ale jeśli chcesz buforować tylko odpowiedzi pod /public URI, możesz ustawić to na CacheEnable disk /public.

My pójdziemy inną drogą, włączając nasz cache w ramach konkretnego bloku lokalizacji. Oznacza to, że nie musimy podawać ścieżki URI do polecenia CacheEnable. Każdy URI, który zostałby obsłużony z tej lokalizacji będzie buforowany. Włączymy również dyrektywę CacheHeader, aby nasze nagłówki odpowiedzi wskazywały, czy cache został użyty do obsłużenia żądania, czy nie.

Inną dyrektywą, którą ustawimy jest CacheDefaultExpire, abyśmy mogli ustawić czas wygaśnięcia (w sekundach), jeśli ani nagłówki Expires, ani Last-Modified nie są ustawione na treści. Podobnie, ustawimy CacheMaxExpire, aby ograniczyć ilość czasu, przez jaki elementy będą zapisywane. Ustawimy CacheLastModifiedFactor, aby Apache mógł utworzyć datę wygaśnięcia, jeśli ma ustawioną datę Last-Modified, ale nie ma wygaśnięcia. Współczynnik jest mnożony przez czas od modyfikacji, aby ustawić rozsądny czas wygaśnięcia.

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 </Location></VirtualHost>

Zapisz i zamknij plik, gdy skonfigurowałeś wszystko, czego potrzebujesz.

Sprawdź całą konfigurację pod kątem błędów składni, wpisując:

sudo apachectl configtest

Jeżeli nie zostaną zgłoszone żadne błędy, uruchom ponownie usługę, wpisując:

sudo service apache2 restart

Ustawianie Expires i nagłówków buforowania treści

W powyższej konfiguracji skonfigurowaliśmy buforowanie HTTP, które opiera się na nagłówkach HTTP. Jednakże, żadna z treści, którą serwujemy nie posiada nagłówków Expires lub Cache-Control potrzebnych do podjęcia inteligentnych decyzji dotyczących buforowania. Aby ustawić te nagłówki, musimy skorzystać z kilku dodatkowych modułów.

Moduł mod_expires może ustawić zarówno nagłówek Expires, jak i opcję max-age w nagłówku Cache-Control. Moduł mod_headers może być użyty do dodania bardziej szczegółowych opcji Cache-Control w celu dalszego dostrojenia polityki buforowania.

Możemy włączyć oba te moduły, wpisując:

 
sudo a2enmod expires
 
sudo a2enmod headers
 

Po włączeniu tych modułów możemy od razu przejść do ponownego modyfikowania naszego pliku wirtualnego hosta:

sudo nano /etc/apache2/sites-enabled/000-default.conf

Moduł mod_expires zapewnia tylko trzy dyrektywy. Dyrektywa ExpiresActive włącza przetwarzanie wygasania w pewnym kontekście, ustawiając ją na „on”. Pozostałe dwie dyrektywy są bardzo podobne do siebie. Dyrektywa ExpiresDefault ustawia domyślny czas wygaśnięcia, a ExpiresByType ustawia czas wygaśnięcia zgodnie z typem MIME zawartości. Obie te dyrektywy ustawią Expires i Cache-Control „max-age” na prawidłowe wartości.

Te dwa ustawienia mogą mieć dwie różne składnie. Pierwsza z nich to po prostu „A” lub „M”, po których następuje liczba sekund. Ustawia to wygaśnięcie w odniesieniu do ostatniego czasu, kiedy zawartość była „dostępna” lub „zmodyfikowana” odpowiednio. Na przykład, obie te wartości spowodują wygaśnięcie zawartości po 30 sekundach od uzyskania do niej dostępu.

ExpiresDefault A30ExpireByType text/html A30

Inna składnia pozwala na bardziej szczegółową konfigurację. Pozwala ona na użycie jednostek innych niż sekundy, które są łatwiejsze do obliczenia przez człowieka. Używa również pełnego słowa „dostęp” lub „modyfikacja”. Cała konfiguracja wygasania powinna być ujęta w cudzysłów, jak poniżej:

ExpiresDefault "modification plus 2 weeks 3 days 1 hour"ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"

Dla naszych celów, po prostu ustawimy domyślne wygasanie. Na początek ustawimy ją na 5 minut, tak aby w przypadku popełnienia błędu podczas zapoznawania się z danymi, nie były one przechowywane na komputerach naszych klientów przez bardzo długi czas. Kiedy będziemy bardziej pewni naszej zdolności do wybierania polityk odpowiednich dla naszej zawartości, możemy dostosować to do czegoś bardziej agresywnego:

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" </Location></VirtualHost>

To ustawi nasz nagłówek Expires na pięć minut w przyszłości i ustawi Cache-Control max-age=300. W celu dalszego dopracowania naszej polityki buforowania, możemy użyć dyrektywy Header. Możemy użyć opcji merge, aby dodać dodatkowe opcje Cache-Control. Możesz wywołać to wiele razy i dodać dowolne dodatkowe polityki, które chcesz. Zapoznaj się z tym przewodnikiem, aby dowiedzieć się jakie zasady buforowania powinieneś ustawić dla swojej zawartości. Dla naszego przykładu, po prostu ustawimy „public”, aby inne cache mogły być pewne, że wolno im przechowywać kopie.

Aby ustawić ETags dla statycznej zawartości na naszej stronie (do użycia przy walidacji), możemy użyć dyrektywy FileETag. Będzie to działać dla statycznej zawartości. Dla dynamicznie generowanej zawartości, twoja aplikacja będzie odpowiedzialna za poprawne wygenerowanie ETags.

Używamy dyrektywy do ustawienia atrybutów, których Apache użyje do obliczenia Etag. Może to być INode, MTime, Size lub All, w zależności od tego, czy chcemy modyfikować ETag za każdym razem, gdy zmieni się inode pliku, zmieni się jego czas modyfikacji, zmieni się jego rozmiar, czy też wszystkie powyższe. Możesz podać więcej niż jedną wartość i możesz modyfikować odziedziczone ustawienia w kontekstach potomnych, poprzedzając nowe ustawienia znakiem + lub -. Dla naszych celów użyjemy po prostu „all”, aby wszystkie zmiany zostały zarejestrowane:

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" Header merge Cache-Control public FileETag All </Location></VirtualHost>

To doda „public” (oddzielone przecinkiem) do wartości Cache-Control, którą już ma, i dołączy ETag dla naszej statycznej zawartości.

Kiedy skończysz, zapisz i zamknij plik. Sprawdź składnię swoich zmian wpisując:

sudo apachectl configtest

Jeśli nie znaleziono błędów, uruchom ponownie usługę, aby wdrożyć politykę buforowania:

sudo service apache2 restart

Podsumowanie

Konfigurowanie buforowania w Apache może wydawać się trudnym zadaniem ze względu na to, jak wiele jest opcji. Na szczęście łatwo jest zacząć w prosty sposób, a następnie rozwijać się, gdy wymagana jest większa złożoność. Większość administratorów nie będzie wymagać każdego z typów buforowania.

Konfigurując buforowanie, pamiętaj o konkretnych problemach, które próbujesz rozwiązać, aby nie pogubić się w różnych opcjach implementacji. Większość użytkowników skorzysta przynajmniej z ustawiania nagłówków. W przypadku proxy lub generowania treści, ustawienie buforowania HTTP może być pomocne. Buforowanie obiektów współdzielonych jest przydatne do specyficznych zadań, takich jak przechowywanie sesji SSL lub szczegółów uwierzytelniania, jeśli używasz dostawcy backendu. Buforowanie plików może być prawdopodobnie ograniczone do osób z wolnymi systemami.