Rozszerzona konfiguracja Apache

Apache 2.x zawiera pewne nowości, które znacznie ułatwiają życie nie tylko webmasterom. Także odwiedzający witrynę internetową utrzymywaną przez Apache zauważą większą szybkość działania i nowe usługi.

Apache 2.x zawiera pewne nowości, które znacznie ułatwiają życie nie tylko webmasterom. Także odwiedzający witrynę internetową utrzymywaną przez Apache zauważą większą szybkość działania i nowe usługi.

Modułowa budowa serwera internetowego Apache umożliwia integrację niemal dowolnych modułów, co z kolei pozwala udostępnić rozliczne funkcje specjalne. W standardowych konfiguracjach większości dystrybucji wiele dostarczanych rozszerzeń nie jest w ogóle aktywowanych, a więc ani administrator, ani odwiedzający nie odczuwają płynących z nich korzyści. Dotarcie do ukrytych skarbów nie jest jednak wcale trudne.

Szczególnie interesujące są następujące możliwości:

  • Kompresja danych redukuje ruch, a zatem i koszty operatora witryny. Dodatkowo strona szybciej dociera do odbiorcy.
  • Mechanizmy buforowania zmniejszają obciążenie serwera i skracają czas odpowiedzi.
  • Uwierzytelnianie chroni określone obszary witryny i umożliwia dostęp jedynie wybranym użytkownikom.
1. Redukcja ruchu za pomocą kompresji danych

Jedne z poważniejszych kosztów eksploatacji witryny internetowej to opłaty za przesyłane dane. Większość informacji pobieranych ze stron internetowych składa się z czystego tekstu (kod HTML i treść tekstowa), a więc łatwo je skompresować. Nie uszło to uwadze programistów serwerów internetowych ani twórców przeglądarek. Nowoczesne serwery i przeglądarki mogą nie tylko operować czystym tekstem, ale mogą również negocjować różne metody kompresji. Przesyłanie spakowanych stron HTML daje wiele korzyści. Po pierwsze, spadają koszty operatora witryny, a w niektórych przypadkach również odbiorcy treści (taryfy uwzględniające ilość pobranych danych). Po drugie, przy tej samej szerokości pasma można obsłużyć więcej użytkowników. Wreszcie po trzecie, strona dociera szybciej do użytkownika. Docenią to przede wszystkim użytkownicy korzystający z modemów.

Webmasterzy korzystający z wersji Apache 1.3.x mogą kompresować dane dopiero po zastosowaniu zewnętrznego modułu dodatkowego mod_gzip ( http://www.schroepl.net/projekte/mod_gzip/ ). Natomiast Apache 2.x już zawiera tę funkcję w postaci modułu mod_deflate. Niestety, w SuSE Linux moduł ten jest z nieznanych powodów domyślnie nieaktywny. Można to szybko zmienić za pomocą niewielkiej modyfikacji konfiguracji.

W tym celu należy najpierw rozszerzyć listę parametrów zmiennej APACHE_MODULES w pliku /etc/sysconfig/apache2 o wartość deflate. W rezultacie podczas następnego startu serwera Apache, wywołanego poleceniem /etc/init.d/apache2 restart, zostanie załadowany moduł Deflate do kompresji przesyłanych danych. Jednak to nie wystarczy do pełnego wykorzystania kompresji danych. Trzeba jeszcze wpisać kilka kolejnych poleceń w pliku /etc/apache2/httpd.conf (listing 1).

Listing 1

<Location />

SetOutputFilter DEFLATE

BrowserMatch ^Mozilla/4 gzip-only-text/html

BrowserMatch ^Mozilla/4\.0[678] no-gzip

BrowserMatch \bMSI[E]!no-gzip!gzip-only-text/html

SetEnvIfNoCase Request_URI \\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Header append Vary User-Agent env=!dont-vary

</Location>

Ta sekwencja może być wykorzystana w dwóch miejscach. Jeżeli umieścisz ją w centralnym pliku konfiguracyjnym httpd.conf, wszystkie strony internetowe wysyłane przez serwer będą kompresowane niezależnie od tego, z którego wirtualnego hosta pochodzą. Możesz dla odmiany umieścić jej dedykowaną wersję w pliku konfiguracyjnym każdego z wirtualnych hostów. W razie ewentualnych problemów zawsze można wyłączyć kompresję którejś z witryn internetowych.

Poszczególne wiersze ze słowem kluczowym Browser Match zapewniają uniknięcie znanych problemów ze starszymi przeglądarkami. Dzięki poleceniu SetEnvIfNoCase serwer internetowy dowiaduje się, że ma nie wysyłać danych graficznych przez filtr kompresji. Wiersze zaczynające się od słowa kluczowego Header dbają o to, żeby znajdujący się ewentualnie między odbiorcą a serwerem internetowym serwer proxy poprawnie przesyłał dane do użytkownika.

Aby sprawdzić, czy kompresja rzeczywiście daje korzyści, w fazie testowej możesz założyć plik dziennika zbierający dane na temat kompresji. Pomoże ci w tym moduł Deflate, udostępniający nowe słowo kluczowe: DeflateFilterNote. Umożliwia ono zastosowanie nowej zmiennej, która służy do tworzenia pliku dziennika według definicji użytkownika (listing 2).

Listing 2

DeflateFilterNote Input instream

DeflateFilterNote Output outstream

DeflateFilterNote Ratio ratio

LogFormat '"%r" %{outstream}n/%{instream}n _

(%{ratio}n%%)' deflate

CustomLog /home/webuser/websites/www.mojadomena. pl/log/

Deflate.log deflate

Moduł Deflate umożliwia z reguły uzyskanie kompresji rzędu 20 procent do 50 procent objętości wyjściowej. Szybsze przesyłanie strony zauważą przede wszystkim użytkownicy korzystający z modemu lub połączenia ISDN. Miły efekt uboczny polega na tym, że mniejsze objętości plików to nie tylko korzyść dla webmastera. Również użytkownicy DSL z taryfą zależną od objętości przesyłanych danych zapłacą niższy rachunek, gdyż otrzymują mniej danych z serwera.

2. Krótszy czas odpowiedzi dzięki buforowaniu

W przypadku często odwiedzanych stron internetowych okazuje się, że wąskim gardłem systemu staje się nie przepustowość połączenia sieciowego, lecz twardy dysk. Apache 2.x oferuje rozwiązanie tego problemu poprzez zastosowanie własnej pamięci cache, korzystającej albo z pamięci roboczej komputera, albo z katalogu na twardym dysku.

Aby skorzystać z pamięci cache, trzeba podczas startu Apache załadować co najmniej dwa z trzech modułów: moduł centralny mod_cache oraz jeden z dwóch modułów pamięci mod_mem_cache lub mod_disk_cache. Warto zastosować podejście dwustopniowe, aby umożliwić łatwe przełączanie między modułami. W tym celu należy rozszerzyć listę parametrów APACHE_MODULES w pliku konfiguracyjnym /etc/sysconfig/apache2 o wartość cache dla modułu centralnego. W pliku konfiguracyjnym serwera internetowego (/etc/apache2/ httpd.conf) musi się znaleźć jeszcze jeden blok poleceń, który będzie przełączać między buforowaniem w pamięci a buforowaniem na dysku (listing 3).

Listing 3

<IfModule mod_cache.c>

#LoadModule disk_cache_module _

/usr/lib/apache2-prefork/mod_disk_cache.so

<IfModule mod_disk_cache.c>

CacheRoot /tmp/cacheroot

CacheSize 256

CacheEnable disk /

CacheDirLevels 5

CacheDirLength 3

</IfModule>

LoadModule mem_cache_module _

/usr/lib/apache2-prefork/mod_mem_cache.so

<IfModule mod_mem_cache.c>

CacheEnable mem /

MCacheSize 4096

MCacheMaxObjectCount 100

MCacheMinObjectSize 1

MCacheMaxObjectSize 2048

</IfModule>

</IfModule>

Zależnie od tego, które z rozpoczynających się od LoadModule poleceń jest w danej chwili aktywne - a więc nie wyłączone komentarzem # - serwer buforuje wszystkie strony na dysku lub w pamięci. Jeżeli okazałoby się, że powoduje to problemy z działaniem niektórych stron, buforowanie można wyłączyć dla poszczególnych hostów wirtualnych poleceniem:

<IfModule mod_cache.c>

CacheDisable /

</IfModule>


Zobacz również