Gdy użytkownicy zaczynają coraz

Transkrypt

1 KNOW HOW Dostrajanie Apache Skuteczna optymalizacja serwerów WWW Szybki jak strzała Nie ma nic bardziej irytującego niż serwer Apache, który nie radzi sobie z odpowiadaniem na żądania klientów i działa zbyt wolno. Webmasterzy znajdują się pod ciągłą presją i nieustannie próbują zapewnić płynność działania serwisów WWW. Przyczyn powolnego działania jest wiele, ale wiele jest także sposobów na rozwiązanie problemu wąskiego gardła. CHRISTIAN KRUSE Gdy użytkownicy zaczynają coraz częściej narzekać na długi czas pobierania dokumentów, webmaster musi coś z tym zrobić. Przyczyn opóźnień może być wiele: zbyt mała przepustowość sieci, przeciążenie serwera lub po prostu zbyt duża liczba zapytań generowana przez użytkowników. W artykule zaprezentowano kilka sposobów przyspieszenie działania serwisów WWW. Omówione zostały również sposoby testowania wprowadzonych zmian za pomocą prostych narzędzi do pomiaru wydajności. Listing 1. Wyniki działania tracepath. 01 ckruse@shine:~ $ tracepath ?: [LOCALHOST] pmtu : fogg.defunced.de ( ) 2.625ms 04 2: ( ) 5.109ms 05 3: gwin-gw-gig hrz.uni-dortmund.de ( ) ms 06 4: ar-essen2.g-win.dfn.de ( ) ms 07 5: cr-essen1-ge4-0.g-win.dfn.de ( ) ms 08 6: cr-frankfurt1-po8-1.g-win.dfn.de ( ) ms 09 7: ( ) ms 10 8: gi-0-3-ffm2.noris.net ( ) ms 11 9: ge nbg5.noris.net ( ) ms 12 10: no.gi-5-1.rs8k1.rz2.hetzner.de ( ) ms 13 11: et-1-16.rs3k1.rz2.hetzner.de ( ) ms 14 12: srv001.occuris.de ( ) ms reached 15 Resume: pmtu 1500 hops 12 back 12 Problemy z siecią i routerem Na pewno lepszą strategią, niż doraźne reagowanie na pojawiające się problemy, jest systematyczna kontrola systemu i zapobieganie potencjalnym kłopotom. Najbardziej prawdopodobnym źródłem problemów jest mała przepustowość sieci i powstawanie wąskiego gardła w miejscach styku z siecią WAN (router) lub niestabilne parametry połączenia. Użytecznymi narzędziami diagnostycznymi w takiej sytuacji są tracepath oraz traceroute, które pozwalają łatwo ustalić przebieg pakietów, wielkość opóźnienia między kolejnymi skokami itp. Takie testy trzeba wykonywać redukując parametr TTL (Time to Live) i oczekując aż router zwróci błąd przekroczenia czasu oczekiwania (TIME_EXCEEDED). Pole TTL najczęściej określa ilość skoków (hops) dozwolonych przy przekazywaniu pakietu przez sieć. Pozwala to administratorom bliżej analizować problemy z połączeniem. Listing 1 pokazuje następujący przykład: router w 4 skoku, ar-essen2.g-win.dfn.de, odpowiada dość wolno. Tym niemniej czas 0,2 sekundy nie jest jeszcze krytyczną wartością, należy zatem założyć, że wąskie gardło występuje jednak gdzieś indziej. Następnym krokiem jest analiza obciążenia serwera. Najlepszym sposobem sprawdzenia Tabela 1. Najważniejsze moduły Apache. Nazwa modułu env_module config_log_module mime_module includes_module autoindex_module dir_module cgi_module action_module gzip_module Nazwa modułu alias_module rewrite_module access_module auth_module setenvif_module headers_module expires_module php4_module 44 Luty

2 Dostrajanie Apache KNOW HOW tego jest monitorowanie serwera podczas standardowej pracy, przez łączenie się do konsoli np. przy pomocy SSH. Narzędzia takie jak top i ps dostarczają ogólnych wskazówek, podobnie wartość uptime, która pozwoli ustalić poziom bieżącego obciążenia serwera. Narzędzie Apachetop, opisywane w Linux Magazine [3], będzie również bardzo przydatne w przeprowadzaniu analizy. Niestety, nie ma żadnej gwarancji, że tak zidentyfikowane wąskie gardło jest elementem stałym; tak naprawdę może ono mieć charakter chwilowy i powstać np. w wyniku przerw w pracy urządzeń sieciowych i awarii łącz. Rozwiązaniem tego problemu jest użycie programu MRTG [4], służącego do rejestrowania działań serwera w dłuższym przedziale czasu. Opis przykładowej instalacji MRTG znajduje się w [5]. Analizowanie wykresów MRTG zwykle ujawnia, że serwer jest przeładowany lub poziom ruchu jest zbyt wysoki. Wykresy średniego obciążenia oraz obciążenia procesora, to wskaźniki pozwalające łatwo wykryć zbyt duże obciążenie serwera. Wykaz liczby aktywnych procesów pozwala zidentyfikować winowajcę. Jeśli liczba procesów pozostaje stała, powinniśmy poszukać procesu, który wymknął się spod kontroli i działa wadliwie, zajmując pamięć i czas procesora. Jednak jeśli liczba procesów się zmienia, należy sprawdzić skrypty CGI, które również mogą blokować zasoby. W tym celu przyda się plik Access.log z Apache oraz lista procesów (uzyskana programem top) zużywających najwięcej zasobów, obejmujące przedział czasu, w którym serwer był w znacznym stopniu obciążony. Dzięki nim można się dowiedzieć, które adresy URL były najczęściej wywoływane. Ta informacja pozwala administratorom zlokalizować skrypt lub program odpowiedzialny za przeciążanie serwera. Zdarza się jednak także tak, że wykresy obciążenia serwera stale przedstawiają niskie wartości, ale poziom ruchu w sieci jest zdecydowanie zbyt wysoki. Czy serwer jest przeciążony? Fakt, że serwer jest mocno obciążony, Rysunek 1. Zmiana parametru Connection Timeout w pliku konfiguracyjnym Apache może zwiększyć wydajność. stanowić powód do niekoniecznie musi zmartwień. Duże i często używane dokumenty, mają tendencję do generowania dużego obciążenia. W wielu przypadkach administrator niewiele może z tym zrobić. Pierwszą rzeczą, której można spróbować, jest ponowne przekompilowanie Testy wydajności są używane do określenia efektywności dokonanej optymalizacji. Dobrym kryterium porównawczym jest mierzenie czasu między otrzymaniem przez serwer zapytania, a dostarczeniem odpowiedzi na nie. Aby to sprawdzić, uruchomiłem 2 komputery PC i podłączyłem je do sieci wewnętrznej 100 MB. Mój serwer (AMD Athlon 600 z 64 MB pamięci SD-RAM) pracował na FreeBSD 4.6 i Apache Charakterystyki serwera WWW opisane w tym artykule odnoszą się również do Apache 2, o ile nie zaznaczono inaczej. Do symulowania prędkości ISDN zainstalowałem również moduł Mod_bandwidth, aby różnice w wydajności były bardziej widoczne. Maszyny klienckie (AMD Duron 800 z 312 MB pamięci SD-RAM) działały Środowisko testowe Rysunek 2. Fragmenty skryptu testowego autora napisanego w Perlu, do ściągnięcia ze stron WWW Linux Magazine. oprogramowania z odpowiednią flagą kompilatora. Wiele popularnych dystrybucji zawiera pakiet Apache, skompilowany do pracy na procesorach serii 386 w celu zachowania kompatybilności. Rekompilacji można dokonać ustawiając flagi kompilacji stosownie do posiadanej platformy sprzętowej. Jeśli twój serwer bazuje na procesorze Athlon (zobacz poniższą tabelę Środowisko testowe ), możesz użyć poniższego zestawu flag: CFLAGS='-march=athlon U -fexpensive-optimizations -O3' Flagi te wskazują kompilatorowi, żeby generował kod maszynowy działający wyłącznie na procesorach typu Athlon. W naszym przykładzie poziom optymalizacji jest ustawiony na 3, co pozwala kompilatorowi użyć zoptymalizowanych metod (kosztem dłuższego czasu kompilacji i kompatybilności). na Gentoo Linux 1.4 z jądrem , i Perl Moje podstawowe narzędzie testujące wydajność, to skrypt napisany przeze mnie w Perlu, który można ściągnąć z [1]. Na rysunku 2 przedstawiono fragment jego działania. Skrypt ściąga adres URL, podany jako argument przy jego wywołaniu, wraz ze wszystkimi odwołaniami potrzebnymi do pomiarów. Skrypt mierzy czas potrzebny do wykonania tego (zobacz rysunek 3). Drugie narzędzie to dostarczony z Apache program ab [2]. Służy on głównie do pomiarów obciążenia. Aby określić jego poziom, narzędzie to symuluje dużą liczbę jednoczesnych zapytań, następnie mierzy liczbę zapytań obsługiwanych przez serwer w czasie jednej sekundy oraz czas potrzebny Apache na ich obsługę. Rysunek 3. Skrypt testowy autora w akcji. Ściąga wybrany adres URL i mierzy czas potrzebny na tą operację. Luty

3 KNOW HOW Dostrajanie Apache Wiele modułów Apache podczas obsługi zapytań tworzy pliki tymczasowe; PHP tworzy jednorazowe pliki, ułatwiające zarządzanie sesją. Dlatego następny krok optymalizacji, to przeniesienie katalogu /tmp z dysku twardego do pamięci (RAM-dysk), standardowo o rozmiarze około 128 MB. Mimo, że Linux używa bardzo efektywnej strategii buforowania danych, RAM-dysk znacznie przyspiesza czas reakcji serwera. Standardowe CGI: Mordercy wydajności Skrypty CGI, działające na serwerze WWW, należy dokładnie przeanalizować. Te niewątpliwie użyteczne pogramy często wywołują problemy z wydajnością, ponieważ uruchomienie ich wymaga przetworzenia plików binarnych. Usunąłem rzeczywiste nazwy hostów, ale poniższy przykład jest z życia wzięty: Serwer WWW, działający w środowisku produkcyjnym, miał bardzo duży i skomplikowany skrypt CGI napisany w Perlu. Gdy serwer zaczął mieć problemy z dużym obciążeniem, odpowiedzialny za jego działanie zespół zmodyfikował zasady działania skryptu tak, aby sprawdzał średnie obciążenie i usuwał procesy CGI w przypadku wykrycia przeciążenia. Skutki były odwrotne do zamierzonych: obciążenie wciąż było bardzo duże, a uruchamianie interpretera i przetwarzanie skryptów zajmowało bardzo dużo zasobów systemu. Następnym krokiem było napisanie 804 bajtowego programu w C, który podejmował decyzje w zależności od wydajności. Gdy obciążenie było zbyt duże, generował informację o błędzie, jeśli nie uruchamiał oryginalny skrypt CGI. Rozwiązanie to okazało się bardzo efektywne, system radził sobie z dużym obciążeniem znacznie lepiej niż w poprzednim przypadku. Programiści mogą iść jeszcze krok dalej i napisać moduł mod_loadavg do serwera Apache i ograniczyć w jeszcze większym stopniu obciążenie serwera. Moduły tego typu pozwalają zrezygnować z wywoływania interpreterów języków programowania. Moduły Apache są dostępne dla wszystkich najważniejszych języków programowania, np.: mod_perl, mod_php, mod_ruby, mod_fastcgi. Dostrajanie HTTPD Sam serwer Apache posiada duże możliwości optymalizacji. Chociaż podstawowa domyślna konfiguracja zazwyczaj wystarcza, niektóre dystrybucje próbują ładować zbyt wiele zbędnych modułów. Do normalnej pracy potrzebne są wyłącznie moduły wymienione w Tabeli 1. Usunięcie zbędnych modułów zmniejszy rozmiar pamięci zajmowany przez proces HTTPD, skróci również czas obsługi zapytań. Dzieje się tak, ponieważ dla każdego obsługiwanego zapytania Apache musi sprawdzić każdy aktywny moduł pod kątem przydatności do jego obsługi. Przyjrzyjmy się teraz jawnym parametrom zapisanym w pliku konfiguracyjnym serwera. Doświadczenie pokazuje, że np. zmniejszenie wartości connection timeout w parametrze Timeout pliku konfiguracyjnego może wiele zmienić. Czy naprawdę trzeba czekać aż 300 sekund, żeby serwer zamknął połączenie, nie doczekawszy się nowego pakiet lub zapytania? Takie powolne zapytania blokują procesy podrzędne i uniemożliwiają przyjmowanie nowych połączeń, które Apache mógłby obsłużyć w międzyczasie. Czas oczekiwania wynoszący sekund powinien wystarczyć, nawet w przypadku klientów korzystających z wolniejszych połączeń internetowych (zobacz Rysunek 1). Administratorzy powinni również sprawdzić, czy opcja Keep Alive jest ustawiona na On. Ten parametr włącza obsługę zapytań przy pomocy Keep Alive. Pozwala ona klientom używać jednego połączenia do obsługi wielu zapytań. W innym przypadku klient musi korzystać z nowego połączenia dla każdego nowego zapytania, a to wiąże się za każdym razem z przejściem przez procedurę nawiązywania połączenia i niepotrzebnym wykorzystaniem trzech dodatkowych pakietów. Przy obciążeniu na poziomie 50 zapytań na sekundę, oznacza to 9000 pakietów na minutę, potrzebnych tylko i wyłącznie na nawiązanie połączeń. W ten sposób, przyjmując, że 3 klientów generuje 50 zapytań, włączenie opcji Keep Alive zredukuje liczbę połączeń na sekundę do 3, a liczbę pakietów potrzebnych do nawiązania tych połączeń do 540. Redukowanie opóźnień Parametr KeepAliveTimeout powinien mieć możliwie niską wartość zwykle wystarcza 15 sekund. Parametr MaxSpareServers ogranicza liczbę bezczynnych procesów httpd. Powoduje to zmniejszenie liczby procesów httpd w okresach mniejszego obciążenia serwera. Oznacza to również, że Apache będzie musiał podzielić kilka nowych procesów httpd w celu obsłużenia zwiększającego się obciążenia. W przypadku serwisów narażonych na czasowe skrajne obciążenia, administratorzy powinni jednak zablokować (wykomentować) ten parametr, monitorując jednocześnie wyniki i sprawdzając, czy efektywność serwera wzrasta. Parametr MaxSpareServers powinien być ustawiony w okresach mniejszego obciążenia, dzięki czemu będziesz miał kontrolę nad ilością procesów httpd. Zupełnie inną funkcję pełni parametr Min- SpareServers. Określa on liczbę bezczynnych procesów, które powinien podtrzymywać w pamięci serwer. Procesy te stanowią rodzaj bufora w razie pojawienia się drastycznych skoków obciążenia. Pamiętaj, że sposób reakcji serwera na poziom obciążenia zależny jest od wyboru odpowiednich modułów. Serwer będzie się zachowywał inaczej w przypadku użycia modułu MPM Multiprocessing Module [6, 7] dostępnego dla Apache 2. Wówczas możesz skorzystać z parametrów w MaxSpareThreads i Min- SpareThreads. W tym przypadku te wartości Listing 2. Rezultaty przed tuningiem. 01 Concurrency Level: Time taken for tests: seconds 03 Complete requests: Failed requests: 0 05 Write errors: 0 06 Total transferred: bytes 07 HTML transferred: bytes 08 Requests per second: [#/sec] (mean) 09 Time per request: [ms] (mean) 10 Time per request: [ms] (mean, across all concurrent requests) 11 Transfer rate: [Kbytes/sec] received Connection Times (ms) 14 min mean[+/-sd] median max 15 Connect: Processing: Waiting: Total: Luty

4 Dostrajanie Apache KNOW HOW Listing 3. Wydajność po tuningu. 01 Concurrency Level: Time taken for tests: seconds 03 Complete requests: Failed requests: 0 05 Write errors: 0 06 Total transferred: bytes 07 HTML transferred: bytes 08 Requests per second: [#/sec] (mean) 09 Time per request: [ms] (mean) 10 Time per request: [ms] (mean, across all concurrent requests) 11 Transfer rate: [Kbytes/sec] received Connection Times (ms) 14 min mean [+/-sd] median max 15 Connect: Processing: Waiting: Total: odnoszą się do liczby wątków w procesie Apache. Ogólnie rzecz biorąc, jest to lepsze rozwiązanie, ponieważ Apache 2 powinien mieć mniejsze problemy z tworzeniem nowych wątków niż nowych procesów. Wątek nie musi posiadać własnego obszaru pamięci, do którego proces musiałby być skopiowany. Ponadto wątek nie posiada własnego identyfikatora (process ID), ale wraz z pozostałymi wątkami współdzieli ID głównego procesu. W poszukiwaniu kompromisu Kolejnym istotnym parametrem jest MaxRequestsPerChild, który usuwa procesy potomne po przetworzeniu pewnej liczby zapytań i tworzy nowe procesy potomne. Jest to przydatna funkcja, ponieważ niektóre biblioteki i moduły są podatne na wycieki pamięci (memory leaks) i należy je co pewien czas przeładować, żeby oczyścić pamięć. Należy jednak wykonać dokładne testy przed włączeniem tego parametru, w celu sprawdzenia, czy stosowanie go jest na pewno potrzebne. Jeśli okaże się, że liczba procesów Apache rośnie gwałtownie podczas okresów wyższego obciążenia (do sprawdzenia tego możesz użyć narzędzia top), w zasadzie nie ma innego wyjścia, jak użycie tego parametru. W tym przypadku należy ustawić wysoką wartość, jest ona zależna od konfiguracji systemu i musi być dobrana metodą prób i błędów. Jest to zawsze kompromis między wydajnością, a stopniem wykorzystania zasobów pamięci. Drugim kompromisowym parametrem jest HostnameLookups. Jeśli priorytetem jest szybkość pracy, należy go ustawić na Off. Uaktywnienie tej opcji wymusza dla każdego zapytania odwrócone (reverse) wyszukiwanie DNS. Powoduje to z kolei wysłanie przynajmniej jednego zapytania do serwera DNS i prowadzi zazwyczaj do generowania kolejnych zapytań DNS do serwerów nazw po stronie zdalnego klienta. Powoduje to nie tylko zwiększony ruch w sieci, ale także zabiera dużo czasu. Na ile skuteczna jest optymalizacja Apache? Dość trudno jest ocenić efekt wykonanej optymalizacji. Skrypt [1] nie nadaje się do przetestowania wprowadzonych zmian, ponieważ nie generuje żadnego obciążenia na serwerze. Test Apache ab (wersja 2, [2]) powinien jednak dostarczyć oczekiwanych informacji (zobacz ramka Środowisko testowe ). Uruchom go przed rozpoczęciem optymalizowania: ckruse@shine:~ $ ab2 -n 100 U -c ExpiresActive On 02 ExpiresByType text/html access plus 1 month 03 ExpiresByType text/css access plus 6 month 04 ExpiresByType text/javascript access plus 6 month 05 ExpiresByType image/gif access plus 6 month 06 ExpiresByType image/jpeg access plus 6 month 07 ExpiresByType image/png access plus 6 month <Files ~ "\.(js css gif jpe?g png)$"> 10 Header append Cache-Control "public" 11 </Files> Program uruchamia 100 faz zapytań, wykonując w każdej fazie jednocześnie po 10 zapytań. Listing 2 pokazuje fragmenty wyników zawierające najważniejsze wartości. Warto spojrzeć na ciekawe wykresy Requests per second (zapytania na sekundę) i Time per request (czas potrzebny na obsłużenie zapytania). Uzyskane tu średnie wartości są interesujące jest to około 35 zapytań na sekundę i 28 milisekund na obsługę każdego zapytania. Po wykonaniu tego testu należy zmienić konfigurację serwera (optymalizując go) i ponownie wykonać test wydajności. Listing 3 pokazuje przykładowe wyniki po wykonaniu optymalizacji. Wygląda na to, że w tym wypadku proces optymalizacji powiódł się całkowicie. Można ostrożnie założyć, że teraz serwer będzie mógł obsłużyć dwukrotnie większą liczbę zapytań. Optymalizacja na poziomie HTTP Optymalizacja na poziomie protokołu HTTP jest związana głównie z obniżaniem poziomu ruchu i zmniejszaniem liczby zapytań, przy czym pomocne będą nagłówki warunkowe (conditional header) i nagłówki buforu (caching header). Nagłówki buforu mówią klientowi (np. przeglądarce WWW), że nie ma potrzeby ponownego pobierania przez określony czas pewnej części danych. Jest to bardzo użyteczne w przypadku statycznego kodu HTML lub arkuszy stylów CSS. Nagłówek Expires wskazuje, kiedy dokument powinien zostać ponownie pobrany (zobacz Listing 4). Jeśli chcesz przekazać do UA (User Agent może to być przeglądarka, proxy lub inny klient), że dokument stał się nieaktualny natychmiast po wygenerowaniu przez Apache i trzeba go pobierać za każdym razem, należy w polu nagłówka wstawić wartość Date. Wartości takie jak now lub 0 są niewłaściwe, ale są akceptowane w celu zwiększenia poziomu tolerancji błędów i przyrównywane do poprzedniej wartości. Od klienta zależy, czy uwzględni tę informację. Listing 4. Ustawianie nagłówków Expires i Cache-Control. Luty

5 KNOW HOW Dostrajanie Apache Listing 5. Przykład zapytania HTTP. 01 $ telnet rain Trying Connected to rain.defunced.de. 04 Escape character is '^]' 05 GET /article/ HTTP/ Host: rain 07 Connection: close HTTP/ OK 10 Date: Sun, 09 Nov :52:04 GMT 11 Server: Apache/ (Unix) PHP/4.2.3 AuthMySQL/ Cache-Control: max-age= Expires: Tue, 09 Dec :52:04 GMT 14 Last-Modified: Tue, 04 Nov :50:42 GMT 15 ETag: "a3a068-1a9d9-3fa83b52" 16 Accept-Ranges: bytes 17 Content-Length: Connection: close 19 Content-Type: text/html <I>HTML contents<i> Nagłówek Cache-Control jest bardziej precyzyjny. Określa ściśle polecenia i parametry buforowania, które każdy klient HTTP zgodny z RFC, musi obsługiwać. Składnia dla Cache- -Control jest nieco inna niż dla Expires. Okres ważności dokumentu jest określany przez parametr max-age=wartość. Wartość jest okresem ważności w sekundach, liczonym od czasu określonego w polu Date. Ustawiając tę wartość na 0 określamy, że dokument nie powinien być w ogóle buforowany, jednak takie rozwiązanie nie jest zalecane. Nagłówki Atrybuty publiczne w nagłówku Cache-Control mogą w pewnych okolicznościach zwiększyć szybkość, ponieważ zezwalają serwerowi proxy na większą swobodę w interpretacji. Jeśli tak poinstruowany serwer proxy odbierze zapytanie, które nie powinno być buforowane, np. zapytanie autoryzacyjne używające HTT- P-Auth, może je zignorować i mimo wszystko zapamiętywać. Obydwa nagłówki wymagają do pracy modułów mod_expires i mod_headers. Administratorzy mogą użyć mod_expires do określenia daty wygaśnięcia ważności dokumentu. Jednakże moduł ten nie obsługuje atrybutu publicznego, więc oznacza to, że będzie potrzebny również mod_headers, aby zezwolić plikom graficznym, skryptom Javascript oraz plikom CSS na jego użycie. Listing 4 pokazuje przykład zapytania HTTP do skonfigurowanego w ten sposób serwera. Zapytanie pokazane na Listingu 5 powinno zostać zapamiętane przez UA (proxy lub przeglądarkę) na okres miesiąca, bez konieczności kontaktowania się w międzyczasie UA z serwerem. Doświadczenie pokazuje jednak, że UA buforują wyniki tylko na krótki czas, najczęściej około dwóch dni, a następnie używają nagłówków warunkowych do sprawdzenia, czy zapamiętana wersja jest aktualna lub czy wymaga uaktualnienia. Do tego celu służy grupa nagłówków rozpoczynających się od If. Dopuszczalne są nagłówki takie jak If- -Match, If-Modified-Since, If-None-Match, If-Range oraz If-Unmodified-Since. Jednak w praktyce nie są one używane, za wyjątkiem If-None-Match (Opera 7 i nowsza oraz Mozilla) i If-Modified-Since (Mozilla, Opera 7, MS Internet Explorer 5.5 oraz nowsze). Pozostałe nagłówki zostały opisane w [8]. Nagłówki warunkowe Wszystkie nagłówki warunkowe odwołują się do pól, które serwer generuje podczas pierwszego zapytania. If-Modified-Since odwołuje się do pola Last-Modified, które zawiera datę ostatniej modyfikacji dokumentu. Nagłówek If-None-Match odwołuje się do ETag, sumy kontrolnej dokumentu. UA zachowuje te wartości i odpowiednio formułuje zapytania (zobacz Listing 6). Jak widać, serwer zwraca odpowiedź 304 Not Modified ('niezmodyfikowany') i kilka innych nagłówków, ale nie odsyła żadnej zawartości. Kilka słów należy poświęcić skryptom CGI. Skrypt CGI powinien wysyłać nagłówek Last-Modified lub ETag, umożliwiający przeglądarce używanie algorytmów warunkowego polecenia GET. Ponadto skrypt musi także przetwarzać nagłówek, ponieważ jest to wymagane do odpowiedniego formatowania daty (zwykle podawanego jako liczba sekund od 1970 roku). Dopiero wtedy można sprawdzić, na podstawie informacji o wersji w nagłówku If-Modified-Since, czy dokument jest aktualny. Podobnie jest w przypadku nagłówka If-None-Match: skrypt oblicza sumę kontrolną i w ten sposób sprawdza, czy wersja dokumentu opisana w nagłówku jest aktualna. Jako algorytmu obliczającego sumę kontrolną można użyć algorytmu haszującego, takiego jak na przykład MD5. Zmienne środowiskowe CGI, HTTP_IF_MODIFIED_SINCE i HTTP_IF_NONE_MATCH umożliwiają dostęp do wartości w obu nagłówkach. Mierzenie wydajności Do zbadania efektywności optymalizacji można użyć skryptu [1] (patrz ramka 'Środowisko testowe'): ckruse@shine:~ $./measure.pl U --base-url Getting [...] Time elapsed: seconds Włączenie obsługi nagłówków warunkowych sprawiło, że całe zapytanie jest przetwarzane w czasie poniżej sekundy. ckruse@shine:~ $./measure.pl U --send-if-modified-since U --send-if-none-match --base-url U Getting [...] Time elapsed: seconds Techniki kompresji Kodowanie zawartości jest inną metodą optymalizowania HTTP. Wymaga ona wysłania przez agenta użytkownika przy zapytaniu o dokument nagłówka Accept-Encoding. Nagłówek określa sposób przetwarzania odpowiedni dla zawartości i może zawierać takie wartości jak: gzip [9] lub compress. Obie wartości okre- Listing 6. Warunkowe polecenie GET. 1 ckruse@shine:~ $ telnet rain Trying Connected to rain.defunced.de. 04 Escape character is '^]'. 05 GET /article/ HTTP/ Host: rain 07 Connection: close 08 If-Modified-Since: Tue, 04 Nov :50:42 GMT 09 If-None-Match: "a3a068-1a9d9-3fa83b52" HTTP/ Not Modified 12 Date: Sun, 09 Nov :28:43 GMT 13 Server: Apache/ (Unix) PHP/4.2.3 AuthMySQL/ Connection: close 15 ETag: "a3a068-1a9d9-3fa83b52" 16 Expires: Tue, 09 Dec :28:43 GMT 17 Cache-Control: max-age= Connection closed by foreign host. 48 Luty

6 Dostrajanie Apache KNOW HOW ślają algorytmy kompresowania zawartości dokumentu, zanim zostanie ona wygenerowana przez serwer oraz sposób rozpakowania jej po stronie klienta. Metoda ta znacznie zmniejsza poziom ruchu w sieci nawet o 90 %. Ma jednak kilka zasadniczych wad: po pierwsze, nie wszyscy agenci potrafią ją obsłużyć np. Netscape 4 wysyła nagłówek Accept-Encoding z wartością gzip, jednak przeglądarka nie obsługuje tej metody poprawnie. Po drugie, proces kompresji zmniejsza wydajność serwera, ponieważ każdy dokument musi zostać odpowiednio spakowany. Po trzecie, technika ta może zostać nieprawidłowo zinterpretowana podczas przekazywania danych przez Internet wiele aplikacji filtrujących zawartość (content filters) usuwa po prostu nagłówek Accept-Encoding, nie sprawdzając go. Ponadto większość serwerów proxy nie reaguje prawidłowo na nagłówek Vary, wymagany dla potrzeb kompresji. Lista nagłówków generowana przez Vary zależy od wariantu zapytania. Starsze wersje linuksowego proxy, Squid HTTP, wyłączają wszelkiego rodzaju nagłówki zawierające parametry ustalające sposoby zapamiętywania. Dlatego zalecamy dokładnie przemyśleć wszystkie zalety i wady wynikające ze stosowania modułu mod_gzip. Szczególnie istotne jest to, kto będzie z serwera korzystać. Optymalizacja na poziomie kodu HTML Pliki HTML posiadają największy potencjał optymalizacyjny. Znaczna część kodu HTML, zwłaszcza przygotowywana dla serwisów firmowych i komercyjnych, jest dostarczana przez projektantów używających edytorów WYSIWYG, takich jak np. Dreamweaver. Edytory te generują jednak dużo nadmiarowego kodu, który bardzo często można skrócić aż o 50 %, bez uszczerbku dla kodu. Generalnie zaleca się usuwanie możliwie wielu sekwencji formatujących z pliku HTML i umieszczanie ich w plikach arkuszy stylów CSS. Z tym zadaniem radzą sobie doskonale nowe edytory WYSIWYG, niestety w przeciwieństwie do ich użytkowników... W odróżnieniu od sekwencji formatujących umieszczonych bezpośrednio w plikach HTML, pliki CSS są ładowane tylko raz, co oznacza, że serwer HTTP tylko raz wysyła sekwencje formatujące. Należy również unikać nadmiernego zagnieżdżania tabeli, jak to się często dzieje w przypadku programu Dreamweaver. Projektanci stron nie powinni traktować kodu wygenerowanego przez tego rodzaju programy jako produktu ostatecznego, lecz jedynie jako prototypu. Taki kod należy uporządkować i oczyścić ze zbędnych sekwencji, używając w tym celu przykładowo narzędzia HTML-Tidy [10]. Obrazy i grafika Projektanci stron mogą znacząco ograniczyć ruch w sieci, zwracając więcej uwagi na obróbkę obrazów i grafiki. Najpopularniejsze formaty obsługiwane przez większość przeglądarek to GIF, JPEG i PNG. Proste rysunki i animacje, to przeważnie pliki GIF, natomiast format JPEG jest używany do zdjęć i obrazów wysokiej jakości mimo iż algorytm JPEG obniża jakość obrazu. Format GIF nie jest przydatny do tego celu, ponieważ może obsługiwać jedynie 256 kolorów. Jeśli najważniejsza jest jakość, to najlepszym wyborem będzie skompresowany format PNG, chociaż rozmiar pliku może być trochę większy niż porównywalnego pliku JPEG. Często spotyka się duże pliki graficzne w wysokiej rozdzielczości, skalowane na stronie WWW przy użyciu parametrów width i height. Takie rozwiązanie ma dwie wady: po pierwsze, oznacza to konieczność niepotrzebnego przesłania dużego pliku. Po drugie, jakość obrazu jest niższa, ponieważ dowolny program do obróbki grafiki pozwala uzyskać dużo lepsze efekty wygładzania i korekcji przy zmniejszaniu pliku niż wewnętrzne mechanizmy przeglądarki. Kiedyś projektanci stron byli ograniczeni powolnymi modemami 14,400 Kb/s i wysoką ceną miejsca na serwerach. Obecnie nie stanowi to już problemu, jednak użytkownicy przyzwyczaili się do zmniejszania obrazków i pozwalają przeglądarce powiększać je z powrotem. Niestety UA niezbyt dobrze radzą sobie z takim zadaniem. Najlepszym rozwiązaniem wydaje się być dobranie takiej skali dla obrazów, aby były wyświetlane w oryginalnym rozmiarze jest to doskonały kompromis między rozmiarem i jakością pliku. Spacje i znaczniki nowej linii HTML jest językiem nie narzucającym wymagań dotyczących formatowania, co pozwala usunąć zbędne spacje i znaki nowej linii. Dla UA jest obojętne, czy kod HTML jest ładnie sformatowany, czy też jest to ciąg znaków w jednym wierszu. Umożliwia to dalsze ograniczenie ruchu w sieci, podobnie jak w przypadku konwersji znaków końca linii w Windows na znaki końca linii w Uniksie, które zajmują jeden bajt zamiast dwóch. Każdy nowoczesny edytor HTML powinien posiadać tę opcję. Użytkownicy Apache 2 mogą użyć w tym celu modułu mod_blanks. Użytkownicy pozostałych wersji Apache mogą uzyskać podobny efekt, używając dwóch odrębnych wersji dokumentu jednej do projektowania, drugiej do publikacji. Po każdej zmianie w pliku do projektowania należy uruchomić prosty skrypt (zobacz [11]). Usuwa on z wersji ostatecznej zbędne spacje i znaki końca linii. Zastosowanie wszystkich omówionych metod optymalizacji powinno przynieść oczekiwany efekt lepszą wydajność serwisu. Będzie to szczególnie dobrze widoczne w przypadku średnio i bardzo obciążonych serwerów. Aby dokładnie określić wpływ wprowadzonych zmian na działanie systemu, należy zawsze przeprowadzać testy wydajności przed i po wykonaniu optymalizacji, używając w tym celu technik omówionych powyżej. [1] Skrypt autora artykułu do pomiaru wydajności: Service/Listings/2004/01/Apache-Tuning [2] Apache benchmarking tool: httpd.apache.org/docs/programs/ab.html [3] Charly Kühnast, The Sysadmin's Daily Grind: Apache Tracking : Linux Magazine, numer 38, strona 54 [4] Multi Router Traffic Grapher: webtools/mrtg [5] Przykładowa instalacja MRTG: [6] Multiprocessing Module: httpd.apache.org/docs-2.0/mpm.html [7] T Grahammer, Apache 2.0 Rules of Succession : Linux Magazine, numer 24, padźiernik 2002, strona 29 [8] HTTP RFC: ftp://ftp.rfc-editor.org/ in-notes/rfc2616.txt [9] U. Keil, Dynamic Webpage Compression with Mod_gzip and Apache : Linux Magazine, numer 24, październik 2002, strona 26 [10] HTML-Tidy: [11] Skrypt do usuwania spacji z plików HTML: AUTOR INFO Christian Kruse studiuje informatykę na uniwersytecie w Dortmundzie. Pracuje dorywczo jako administrator i jest odpowiedzialny za wiele serwerów pracujących pod kontrolą Linuksa i FreeBDS. Luty