Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00061 008459 10460761 na godz. na dobę w sumie
Tomcat. Przewodnik encyklopedyczny. Wydanie II - książka
Tomcat. Przewodnik encyklopedyczny. Wydanie II - książka
Autor: , Liczba stron: 496
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-1594-0 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> serwery internetowe >> inne
Porównaj ceny (książka, ebook, audiobook).

Poznaj możliwości serwera Tomcat!

Tomcat jest kontenerem serwletów Java i serwerem WWW stworzonym przez organizację Apache Software Foundation. Może pełnić rolę serwera produkcyjnego o dużej wydajności, sprawdza się również jako darmowy kontener serwletów i stron JSP z udostępnionym kodem źródłowym. Tomcat może być zastosowany niezależnie lub w połączeniu z innymi serwerami WWW (np. httpd Apache). Doskonale radzi sobie w każdego rodzaju środowisku, zapewniając fundament wymagany do praktycznego wykorzystania w Internecie umiejętności z zakresu technologii Java.

W książce 'Tomcat. Przewodnik encyklopedyczny' znajdziesz szczegółowe wyjaśnienia, jak korzystać z tego serwera. Czytając ją, poznasz wszelkie procedury instalacyjne oraz możliwości konfigurowania obszarów, ról, użytkowników i zasobów JNDI. Nauczysz się, jak uaktywniać i wyłączać funkcję automatycznego przeładowywania serwletów, a także wdrażać aplikacje WWW. Niezbędne informacje dotyczące serwera Tomcat znajdą tu nie tylko programiści, ale także administratorzy, webmasterzy i wszyscy, którzy chcą się dowiedzieć czegoś o tym kontenerze serwletów.

Przewodnik dla wszystkich, którzy chcą ułatwić sobie pracę z serwerem Tomcat.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tomcat. Przewodnik encyklopedyczny. Wydanie II Autor: Jason Brittain, Ian Darwin T‡umaczenie: Piotr Pilch ISBN: 978-83-246-1594-0 Tytu‡ orygina‡u: Tomcat: The Definitive Guide, 2nd edition Stron: 490 Poznaj mo¿liwo(cid:156)ci serwera Tomcat! (cid:149) Jak dostroi(cid:230) Tomcat w celu pomiaru i poprawy wydajno(cid:156)ci? (cid:149) Jak wdra¿a(cid:230) aplikacje WWW z serwletami i stronami JSP? (cid:149) Jak diagnozowa(cid:230) problemy z serwerem? Tomcat jest kontenerem serwlet(cid:243)w Java i serwerem WWW stworzonym przez organizacjŒ Apacze Software Foundation. Mo¿e pe‡ni(cid:230) rolŒ serwera produkcyjnego o du¿ej wydajno(cid:156)ci, sprawdza siŒ r(cid:243)wnie¿ jako darmowy kontener serwlet(cid:243)w i stron JSP z udostŒpnionym kodem (cid:159)r(cid:243)d‡owym. Tomcat mo¿e by(cid:230) zastosowany niezale¿nie lub w po‡„czeniu z innymi serwerami WWW (np. httpd Apache). Doskonale radzi sobie w ka¿dego rodzaju (cid:156)rodowisku, zapewniaj„c fundament wymagany do praktycznego wykorzystania w Internecie umiejŒtno(cid:156)ci z zakresu technologii Java. W ksi„¿ce (cid:132)Tomcat. Przewodnik encyklopedyczny(cid:148) znajdziesz szczeg(cid:243)‡owe wyja(cid:156)nienia, jak korzysta(cid:230) z tego serwera. Czytaj„c j„, poznasz wszelkie procedury instalacyjne oraz mo¿liwo(cid:156)ci konfigurowania obszar(cid:243)w, r(cid:243)l, u¿ytkownik(cid:243)w i zasob(cid:243)w JNDI. Nauczysz siŒ, jak uaktywnia(cid:230) i wy‡„cza(cid:230) funkcjŒ automatycznego prze‡adowywania serwlet(cid:243)w, a tak¿e wdra¿a(cid:230) aplikacje WWW. NiezbŒdne informacje dotycz„ce serwera Tomcat znajd„ tu nie tylko programi(cid:156)ci, ale tak¿e administratorzy, webmasterzy i wszyscy, kt(cid:243)rzy chc„ siŒ dowiedzie(cid:230) czego(cid:156) o tym kontenerze serwlet(cid:243)w. (cid:149) Instalowanie i konfigurowanie Tomcata (cid:149) Zarz„dzanie obszarami, rolami i u¿ytkownikami (cid:149) Uruchamianie i zatrzymywanie serwera (cid:149) Kontrolowanie i utrwalanie sesji (cid:149) Optymalizowanie wydajno(cid:156)ci serwera (cid:149) Integracja z serwerem WWW Apache (cid:149) Wdra¿anie rozpakowanego katalogu aplikacji WWW (cid:149) Praca z plikami WAR (cid:149) Zabezpieczenia serwera Tomcat Przewodnik dla wszystkich, kt(cid:243)rzy chc„ u‡atwi(cid:230) sobie pracŒ z serwerem Tomcat Wydawnictwo Helion ul. Ko(cid:156)ciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Spis treści Przedmowa ...............................................................................................................................9 1. Tomcat — wprowadzenie ............................................................................................17 17 32 44 50 51 Instalowanie Tomcata Uruchamianie, zatrzymywanie i ponowne ładowanie serwera Tomcat Automatyczne uruchamianie Testowanie instalacji serwera Tomcat Skąd się wziął Tomcat? 2. Konfigurowanie Tomcata ...........................................................................................53 53 54 57 65 69 70 84 90 92 92 93 94 95 Coś na temat użycia serwera WWW Apache Zmiana lokalizacji katalogu aplikacji WWW Zmiana numeru portu 8080 na inny Konfigurowanie wirtualnej maszyny Java Zmiana kompilatora stron JSP Zarządzanie obszarami, rolami i użytkownikami Kontrolowanie sesji Uzyskiwanie dostępu do zasobów JNDI i JDBC Automatyczne ponowne ładowanie serwletów Dostosowywanie katalogów użytkowników Przykładowe aplikacje serwera Tomcat Interfejs CGI Aplikacja WWW administrująca serwerem Tomcat 3. Wdrażanie w obrębie serwera Tomcat aplikacji WWW z serwletami i stronami JSP ........................................................................................101 107 Struktura aplikacji WWW Wdrażanie rozpakowanego katalogu aplikacji WWW 110 114 Wdrażanie pliku WAR 119 Wdrażanie „na gorąco” Praca z plikami WAR 121 122 Aplikacja Manager 125 Automatyzowanie za pomocą narzędzia Apache Ant Dowiązania symboliczne 138 5 4. Optymalizowanie wydajności serwera Tomcat ........................................................141 142 167 170 178 181 Pomiar wydajności serwera WWW Zewnętrzne dostrajanie Wewnętrzne dostrajanie Planowanie obciążenia Dodatkowe źródła informacji 5. Integracja z serwerem WWW Apache ...................................................................... 183 Zalety i wady integracji 184 189 Instalowanie serwera httpd Apache Integrowanie serwera Apache z Tomcatem 191 6. Zabezpieczenia serwera Tomcat .............................................................................. 215 216 218 219 223 227 Zabezpieczanie systemu Wiele modeli zabezpieczeń serwera Zastosowanie narzędzia SecurityManager Nadawanie uprawnień do plików Tworzenie „klatki” narzędzia chroot Tomcata Odfiltrowywanie danych wprowadzonych przez użytkownika ze złymi zamiarami Zabezpieczanie serwera Tomcat za pomocą protokołu SSL 237 255 7. Konfiguracja ................................................................................................................271 272 329 345 346 346 348 Plik server.xml Plik web.xml Plik tomcat-users.xml Plik catalina.policy Plik catalina.properties Plik context.xml 8. Rozwiązywanie problemów i debugowanie ...........................................................349 349 350 351 355 356 Analizowanie plików dzienników Szukanie błędów Adresy URL i komunikacja HTTP Debugowanie za pomocą narzędzia RequestDumperValve Gdy nie udaje się wyłączyć serwera Tomcat 9. Tworzenie binariów serwera Tomcat z kodu źródłowego ...................................... 361 362 363 365 366 Instalowanie oprogramowania Apache Ant Uzyskiwanie kodu źródłowego Pobieranie dodatkowych bibliotek Budowanie serwera Tomcat 6 | Spis treści 10. Klaster węzłów z serwerem Tomcat ........................................................................369 370 371 381 385 402 402 Pojęcia związane z klastrem Proces komunikacji związany z żądaniem HTTP Rozproszone kontenery serwletów Java Implementacja klastra w serwerze Tomcat 6 Dystrybucja żądań JDBC i przełączanie po awarii Dodatkowe źródła informacji 11. Podsumowanie ..........................................................................................................405 405 408 Dodatkowe zasoby Społeczność A Instalowanie środowiska uruchomieniowego Java .................................................411 412 413 416 417 418 419 420 423 Wybieranie pakietu JDK Radzenie sobie ze starszymi wirtualnymi maszynami Java pakietów GCJ i Kaffe Sun Microsystems Java SE JDK IBM J9 JDK BEA JRockit JDK Apple Java SE JDK Excelsior JET Apache Harmony JDK B Plik jbchroot.c ............................................................................................................425 C Plik BadInputValve.java ............................................................................................ 431 D Plik BadInputFilter.java .............................................................................................439 E Pliki pakietu RPM ....................................................................................................... 451 Skorowidz ............................................................................................................................. 471 Spis treści | 7 ROZDZIAŁ 4. Optymalizowanie wydajności serwera Tomcat Po zainstalowaniu i uruchomieniu serwera Tomcat Czytelnik prawdopodobnie będzie chciał zoptymalizować jego wydajność, żeby efektywniej obsługiwał żądania trafiające do komputera. W tym rozdziale przedstawimy kilka pomysłów dotyczących optymalizowania wydajności środowiska uruchomieniowego i samego serwera Tomcat. Sztuka dostrajania serwera jest złożonym zadaniem. Składa się z pomiaru, analizy, modyfi- kacji i ponownie pomiaru. Oto podstawowe kroki procesu optymalizowania: 1. Zdecydowanie, co ma być zmierzone. 2. Określenie metody pomiaru. 3. Pomiar. 4. Przeanalizowanie wniosków wynikających z uzyskanych informacji. 5. Zmodyfikowanie konfiguracji przy wykorzystaniu metod, które powinny poprawić osiągi. 6. Pomiar i porównanie wyników z poprzednio uzyskanymi. 7. Ponowne zrealizowanie kroku 4. Warto zauważyć (co zresztą widać), że nie jest dostępna klauzula „wyjścia z pętli” (być może odzwierciedlająca rzeczywistość). W praktyce trzeba będzie określić próg, poniżej którego mniej istotne zmiany będą tak mało znaczące, że będzie można zająć się innymi codziennymi zmartwieniami. Dostosowywanie i pomiar można zakończyć, gdy uzyska się przekonanie, że wystarczająco bliskie są czasy odpowiedzi, które spełnią postawione wymagania. Aby zdecydować, co należy zoptymalizować w celu osiągnięcia lepszej wydajności, powinno się przeprowadzić niżej opisane działania. Na komputerze testowym należy uruchomić serwer Tomcat tak samo skonfigurowany jak w przypadku środowiska produkcyjnego. Warto zastosować taki sam sprzęt, system operacyj- ny, bazę danych itp. Im bardziej środowisko testowe będzie przypominać produkcyjne, tym większe będą szanse zidentyfikowania wąskich gardeł, które pojawią się w konfiguracji śro- dowiska produkcyjnego. 141 Na oddzielnym komputerze należy zainstalować i skonfigurować generator obciążenia i opro- gramowanie mierzące czasy odpowiedzi, które posłuży do testowania obciążenia. Jeśli opro- gramowanie uruchomi się na tym samym komputerze co serwer Tomcat, wyniki testów będą nie do końca precyzyjne, a czasami nieprawdziwe. W idealnej sytuacji Tomcat powinien działać na jednym komputerze, a oprogramowanie testujące na innym. Jeżeli nie dysponuje się wy- starczającą liczbą komputerów, nie pozostaje nic innego, jak całe oprogramowanie załadować na testowym komputerze. Testy przeprowadzone w ten sposób będą lepsze od zupełnego zrezygnowania z nich. Jednak uruchomienie na tym samym komputerze klienta sprawdzają- cego obciążenie i serwera Tomcat spowoduje, że uzyska się krótsze czasy odpowiedzi, które przy kolejnych powtórzeniach tego samego testu okażą się mniej zgodne. Należy wyizolować komunikację między komputerem testującym obciążenie i komputerem, na którym uruchomiono serwer Tomcat. Jeśli przeprowadza się intensywne testy, nie będzie pożądane zniekształcanie ich danych przez ruch sieciowy niestanowiący części testów. Ponadto nie będzie mile widziane obciążanie komputerów niezaangażowanych w testy na skutek du- żego ruchu sieciowego generowanego przez testy. Między komputerem testującym i serwerem produkcyjnym należy umieścić przełącznik lub zastosować koncentrator, do którego podłą- czono tylko te dwa komputery. Należy przeprowadzić kilka testów obciążenia, symulujących różnego typu sytuacje charak- teryzujące się dużym ruchem sieciowym, które mogą wystąpić w przypadku serwera pro- dukcyjnego. Aby lepiej przygotować się na przyszłą rozbudowę środowiska, dodatkowo powinno się prawdopodobnie wykonać kilka testów generujących ruch sieciowy większy od oczekiwanego w przypadku serwera produkcyjnego. Należy zidentyfikować wszelkie nietypowo długie czasy odpowiedzi i spróbować stwierdzić, jakie składniki sprzętowe i (lub) programowe są tego przyczyną. Zazwyczaj odpowiada za to oprogramowanie. Jest to dobra wiadomość, gdyż w pewnym stopniu problem z długim cza- sem odpowiedzi można zmniejszyć przez przekonfigurowanie lub przebudowanie aplikacji. Jednak w ekstremalnych przypadkach może być konieczne użycie dodatkowego sprzętu lub nowszych, szybszych i kosztowniejszych urządzeń. Obserwować należy średnie obciążenie komputera serwera, a także w plikach dzienników Tomcata szukać komunikatów o błędzie. W niniejszym rozdziale zaprezentujemy niektóre z typowych ustawień serwera Tomcata kwalifi- kujących się do dostrojenia, w tym związane z wydajnością serwera WWW, pulą wątków żądań Tomcata, wydajnością wirtualnej maszyny Java, konfiguracją sprawdzania adresów usługi DNS i wstępną kompilacją stron JSP. Na końcu rozdziału wspomnimy o planowaniu obciążenia. Pomiar wydajności serwera WWW Pomiar wydajności serwera WWW jest groźnie wyglądającym zadaniem, któremu w tym miejscu powinniśmy poświęcić trochę uwagi i podać odnośniki do bardziej obszernych prac poświęconych tej tematyce. Z wydajnością serwera WWW jest związanych zbyt wiele zmien- nych, żeby w pełni omówić to zagadnienie. Większość strategii pomiaru wykorzystuje pro- gram-klienta, który pełni rolę przeglądarki, lecz w rzeczywistości mniej więcej w tym samym czasie wysyła ogromną liczbę żądań i mierzy czasy odpowiedzi1. 1 Istnieje też rozwiązanie serwerowe polegające na uruchamianiu Tomcata pod kontrolą narzędzia Java Profiler w celu zoptymalizowania kodu serwera. Jednak będzie to bardziej interesujące dla programistów niż admini- stratorów. 142 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat Trzeba zdecydować, jak zostanie przeprowadzony test i co dokładnie będzie sprawdzane — czy na przykład powinno się na tym samym komputerze uruchamiać klienta testującego ob- ciążenie i pakiety oprogramowania serwerowego. Szczególnie odradzamy robienie czegoś takiego. Załadowanie klienta i serwera na tym samym komputerze spowoduje zmienności i niestabilność uzyskiwanych wyników. Czy w chwili wykonywania testów na komputerze serwera coś innego jest aktywne? Czy klient i serwer powinny być połączone ze sobą za po- średnictwem łącza Gigabit Ethernet, 100baseT czy 10baseT? Z doświadczenia wiemy, że jeśli klient testujący obciążenie jest podłączony do komputera serwera za pomocą łącza wolniejszego niż Gigabit Ethernet, samo połączenie sieciowe może spowolnić testy, a tym samym zmienić ich rezultat. Czy klient powinien wielokrotnie żądać tej samej strony, jednocześnie generować kilka różnego typu żądań, czy losowo wybierać stronę z dużej listy stron? Może to mieć wpływ na wydaj- ność serwera dotyczącą buforowania i wielowątkowości. To, jak się w tym przypadku postą- pi, będzie zależeć od rodzaju symulowanego klienta obciążenia. Jeżeli symulowane są dzia- łania użytkowników, prawdopodobnie będą oni żądali różnych stron, a nie jednej za każdym razem. Jeśli symuluje się programowego klienta HTTP, może on wielokrotnie żądać tej samej strony. W związku z tym klient testujący powinien raczej robić to samo. Najpierw należy okre- ślić typ ruchu sieciowego generowanego przez klienty, a następnie tak skonfigurować klienty testujące obciążenie, żeby zachowywały się jak klienty rzeczywiste. Czy klient testujący powinien wysyłać żądania regularnie czy seriami? Gdy podczas pomia- rów chce się stwierdzić, jak szybko serwer jest w stanie w pełni obsłużyć żądania, powinno się spowodować, żeby klient testujący wysyłał żądania jedno po drugim bez żadnych przerw między kolejnymi. Czy aktywny serwer korzysta z ostatecznej konfiguracji, czy w dalszym ciągu jest realizowany proces debugowania, który może generować dodatkowe obciążenie? W czasie pomiarów powinno się wyłączyć wszystkie funkcje procesu debugowania. Można również zrezygnować z części operacji rejestrowania. Czy klient HTTP powinien żądać obrazów, czy po prostu strony HTML z osadzonymi obrazami? Zależy to od tego, jak dokładnie zamie- rza się symulować ruch generowany przez użytkowników korzystających z witryn interne- towych. Mamy nadzieję, że Czytelnik doszedł do następującego wniosku: istnieje wiele różnego typu testów wydajności, które można przeprowadzić, i każdy z nich da odmienne (i raczej interesujące) wyniki. Narzędzia testujące obciążenie Zadaniem postawionym przed większością narzędzi mierzących obciążenie związane z wi- trynami internetowymi jest zażądanie jednego lub większej liczby zasobów serwera WWW określoną (dużą) liczbę razy i dokładne poinformowanie użytkownika, ile czasu proces ten potrwał z punktu widzenia klienta (lub ile razy w ciągu sekundy strona mogła zostać pobrana). W internecie jest dostępnych wiele narzędzi mierzących obciążenie witryn WWW (pod adre- sem http://www.softwareqatest.com/qatweb1.html#LOAD znajduje się lista z niektórymi z tych narzędzi). Wśród godnych uwagi narzędzi pomiarowych należy wymienić takie, jak Apache Benchmark (program ab dołączony do dystrybucji serwera httpd Apache dostępnego pod adre- sem http://httpd.apache.org), siege (http://www.joedog.org/JoeDog/Siege) i JMeter wchodzący w skład oprogramowania Apache Jakarta (http://jakarta.apache.org/jmeter). Z tych trzech narzędzi testujących obciążenie najwięcej funkcji oferuje program JMeter. Narzę- dzie to napisano w czystym wieloplatformowym języku Java. Cechuje się ładnym graficznym Pomiar wydajności serwera WWW | 143 interfejsem użytkownika, który jest wykorzystywany zarówno do konfigurowania, jak i ge- nerowania wykresów obciążenia. Program JMeter jest bogaty w możliwości i wyróżnia się ela- stycznością w zakresie testowania witryn i generowania raportów. Można go uruchomić w try- bie tekstowym. Do narzędzia dołączono szczegółową dokumentację sieciową, objaśniającą, jak je skonfigurować i obsługiwać. Z doświadczenia wiemy, że program JMeter zapewnia dla wyników testów większość opcji raportowania, cechuje się największą przenośnością na różne systemy operacyjne i obsługuje większość funkcji. Jednak z jakiegoś powodu nie mógł genero- wać w ciągu sekundy tak wielu żądań HTTP jak narzędzia ab i siege. Jeśli nie próbuje się stwier- dzić, ile serwer Tomcat może obsłużyć żądań na sekundę, program JMeter dobrze się spraw- dzi, gdyż prawdopodobnie zastosuje wszystkie funkcje wymagane przez użytkownika. Jeżeli jednak podejmie się próbę określenia maksymalnej liczby żądań z powodzeniem zrealizowa- nych w ciągu sekundy przez serwer, powinno się sięgnąć po narzędzie ab lub siege. Jeśli szuka się narzędzia pomiarowego trybu wiersza poleceń, program ab sprawdzi się w tej roli znakomicie. Ponieważ jest to wyłącznie narzędzie pomiarowe, raczej nie użyje się go do przeprowadzenia testów regresji. Choć program ab nie oferuje graficznego interfejsu użytkow- nika i jednocześnie nie można mu przekazać listy liczącej więcej niż jeden adres URL, wyjątkowo dobrze radzi sobie z wykonaniem pomiaru dla jednego adresu, a następnie zaprezentowa- niem precyzyjnych i szczegółowych wyników. W większości systemów operacyjnych innych niż Windows narzędzie ab jest domyślnie instalowane z serwerem httpd Apache. Można też skorzystać z oficjalnego pakietu serwera httpd Apache zawierającego narzędzie ab, dzięki czemu będzie ono najprostsze do zainstalowania spośród wszystkich narzędzi testujących obciążenie witryn internetowych. siege jest następnym dobrym narzędziem trybu wiersza poleceń (bez graficznego interfejsu), które testuje obciążenie witryn internetowych. Choć w przypadku większości systemów opera- cyjnych program siege nie jest domyślnie instalowany, instrukcje dotyczące procesu jego budowania i instalowania są zrozumiałe i wyjątkowo proste. Kod narzędzia siege napisany w języku C cechuje się dużą przenośnością. Program obsługuje wiele różnych metod uwierzy- telniania, może przeprowadzić test porównawczy i regresji, a także oferuje tryb internetowy, w którego przypadku próbuje bardziej dokładnie symulować obciążenie aplikacji WWW gene- rowane przez wielu rzeczywistych użytkowników internetowych. Wydaje się, że inne narzędzia, o mniejszych możliwościach, kiepsko obsługują uwierzytelnianie aplikacji WWW. Programy te umożliwiają wysyłanie plików cookie, lecz część z nich może nie pozwalać na odbieranie tych plików. Choć serwer Tomcat obsługuje kilka różnych metod uwierzytelniania (podstawowe, szyfrowane, formularza i z zastosowaniem certyfikatu klienta), część z tych prostszych na- rzędzi jest zgodna jedynie z podstawowym uwierzytelnianiem HTTP. Uwierzytelnianie for- mularza może być przetestowane przez dowolne narzędzie mogące wysyłać formularz (zależy to od tego, czy program obsługuje przekazywanie żądań POST HTTP dotyczących przesłania formularza logowania; żądania POST mogą być wysyłane przez narzędzia JMeter, ab i siege). Coś takiego jest możliwe tylko w przypadku niektórych z bardziej ograniczonych narzędzi. Możliwość dokładniejszego symulowania uwierzytelniania użytkownika w środowisku pro- dukcyjnym jest istotnym elementem testów wydajności, gdyż sam proces uwierzytelniania często generuje duże obciążenie i zmienia charakterystyki wydajnościowe witryny interne- towej. Zależnie od metody uwierzytelniania wykorzystywanej w środowisku produkcyjnym, może być konieczne poszukanie innych narzędzi, które metodę tę obsługują. Gdy książkę przygotowano do druku, pojawił się nowy pakiet oprogramowania porównawczego o nazwie Faban (http://faban.sunsource.net). Narzędzie Faban zostało stworzone przez firmę 144 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat Sun Microsystems w czystym języku Java 1.5+. Jest to oprogramowanie open source objęte li- cencją CDDL. Narzędzie Faban wydaje się skoncentrowane wyłącznie na dokładnym porów- nywaniu różnego typu serwerów, w tym serwerów WWW. Ponieważ narzędzie to zostało do- pracowane w celu zapewnienia wysokiej wydajności i krótkich czasów odpowiedzi, wszelkie pomiary będą jak najbardziej zbliżone do rzeczywistych osiągów serwera. Dane pomiarowe są na przykład zbierane, gdy nie jest wykonywany żaden inny kod narzędzia Faban, a anali- za danych ma miejsce tylko po zakończeniu pomiarów. Aby uzyskać jak najlepszą dokładność, właśnie w taki sposób wszystkie testy pomiarowe powinny być realizowane. Oprogramowa- nie Faban dysponuje również bardzo ładną konsolą konfiguracyjną i administracyjną w postaci aplikacji WWW. W celu obsługi tej konsoli narzędzie Faban jest zintegrowane z serwerem Tomcat! Tak, Tomcat stanowi część programu Faban. Każdy projektant używający języka Java, zainteresowany zarówno Tomcatem, jak i pomiarami wydajności, może zapoznać się z dokumentacją i kodem źródłowym Fabana, a także opcjonalnie uczestniczyć w procesie tworzenia oprogramowania Faban. Jeśli Czytelnik programuje w języku Java i szuka długoter- minowego rozwiązania porównawczego, cechującego się jak największą liczbą możliwości, prawdopodobnie Faban jest tym, co powinno się zastosować. Choć nie dysponowaliśmy ilością czasu pozwalającą nam na opisanie w książce narzędzia Faban w szerszym zakresie, na szczęście jego witryna udostępnia znakomitą dokumentację. ab — narzędzie serwera Apache mierzące wydajność Narzędzie ab pobiera pojedynczy adres URL i żąda go każdorazowo, korzystając z liczby wąt- ków określonych przez użytkownika. ab oferuje różne argumenty wiersza poleceń kontrolujące liczbę pobrań adresu URL i pozwala ustalić maksymalną liczbę jednoczesnych wątków. Wśród kilku przydatnych funkcji programu ab można wyróżnić opcjonalną możliwość okre- sowego drukowania raportów dotyczących postępu operacji i kompletnych raportów. Przykład 4.1 prezentuje zastosowanie narzędzia ab. Zostało ono poinstruowane do pobrania adresu URL 100 000 razy z jednoczesnym wykorzystaniem 149 wątków. Ustawiliśmy takie wartości z rozwagą. Im mniejsza liczba żądań HTTP tworzonych przez klienta testującego w czasie testu porównawczego, tym większe prawdopodobieństwo tego, że klient poda mniej dokładne wyniki. Wynika to stąd, że podczas testu porównawczego wstrzymywanie procesu przez składnik wirtualnej maszyny Java odpowiedzialny za zbieranie zwolnionych obszarów pamięci (ang. garbage collector) powoduje zwiększenie procentowego udziału tego składnika w całkowitym czasie trwania testu. Im wyższa całkowita liczba wygenerowanych żądań HTTP, tym mniej znaczące stają się przerwy wywołane przez składnik zbierający zwol- nione obszary pamięci i tym bardziej prawdopodobne jest to, że wyniki pomiarów pokażą, jak ogólnie działa serwer Tomcat. Testy wydajności powinno się przeprowadzać przez utwo- rzenie co najmniej 100 000 żądań HTTP. Poza tym można tak skonfigurować klienta testującego, żeby wywoływał żądaną liczbę wątków. Jednak nie uzyska się pomocnych wyników, jeśli ustawiona liczba wątków przekroczy wartość argumentu maxThreads określonego w obrębie elementu Connector znajdującego się w pliku conf/server.xml serwera Tomcat. Domyślnie war- tością tego argumentu jest 150. Jeżeli dla klienta testującego ustawi się wyższą wartość i wy- generuje się więcej żądań w liczbie wątków przekraczającej liczbę wątków Tomcata, które od- bierają i przetwarzają te żądania, wydajność spadnie, gdyż część wątków z żądaniami klienta zawsze będzie musiała czekać. Najlepiej po prostu ustawić liczbę wątków klienta mniejszą od wartości atrybutu maxThreads elementu Connector (na przykład 149). Pomiar wydajności serwera WWW | 145 Przykład 4.1. Pomiar wydajności za pomocą narzędzia ab $ ab -k -n 100000 -c 149 http://host_tomcata:8080 This is ApacheBench, Version 2.0.40-dev $Revision$ apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/ Benchmarking tomcathost (be patient) Completed 10000 requests Completed 20000 requests Completed 30000 requests Completed 40000 requests Completed 50000 requests Completed 60000 requests Completed 70000 requests Completed 80000 requests Completed 90000 requests Finished 100000 requests Server Software: Apache-Coyote/1.1 Server Hostname: tomcathost Server Port: 8080 Document Path: / Document Length: 8132 bytes Concurrency Level: 149 Time taken for tests: 19.335590 seconds Complete requests: 100000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 79058 Total transferred: 830777305 bytes HTML transferred: 813574072 bytes Requests per second: 5171.81 [#/sec] (mean) Time per request: 28.810 [ms] (mean) Time per request: 0.193 [ms] (mean, across all concurrent requests) Transfer rate: 41959.15 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 4.0 0 49 Processing: 2 26 9.1 29 62 Waiting: 0 12 6.0 13 40 Total: 2 28 11.4 29 65 Percentage of the requests served within a certain time (ms) 50 29 66 30 75 31 80 45 90 47 95 48 98 48 99 49 100 65 (longest request) Jeśli w wierszu polecenia ab nie umieści się argumentu -k, narzędzie nie będzie korzystać z ciągle aktywnych połączeń z serwerem Tomcat. Jest to mniej efektywne rozwiązanie, ponie- waż w celu utworzenia każdego żądania HTTP narzędzie ab musi połączyć się z Tomcatem przy użyciu nowego gniazda TCP. W rezultacie w ciągu sekundy może być obsłużona mniejsza liczba żądań, a ponadto będzie mniejsza przepustowość między serwerem Tomcat i klientem (programem ab) (przykład 4.2). 146 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat Przykład 4.2. Pomiar wydajności za pomocą narzędzia ab z wyłączoną funkcją ciągle aktywnych połączeń $ ab -n 100000 -c 149 http://host_tomcata:8080/ This is ApacheBench, Version 2.0.40-dev $Revision$ apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/ Benchmarking tomcathost (be patient) Completed 10000 requests Completed 20000 requests Completed 30000 requests Completed 40000 requests Completed 50000 requests Completed 60000 requests Completed 70000 requests Completed 80000 requests Completed 90000 requests Finished 100000 requests Server Software: Apache-Coyote/1.1 Server Hostname: tomcathost Server Port: 8080 Document Path: / Document Length: 8132 bytes Concurrency Level: 149 Time taken for tests: 28.201570 seconds Complete requests: 100000 Failed requests: 0 Write errors: 0 Total transferred: 831062400 bytes HTML transferred: 814240896 bytes Requests per second: 3545.90 [#/sec] (mean) Time per request: 42.020 [ms] (mean) Time per request: 0.282 [ms] (mean, across all concurrent requests) Transfer rate: 28777.97 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 18 11.3 19 70 Processing: 3 22 11.3 22 73 Waiting: 0 13 8.4 14 59 Total: 40 41 2.4 41 73 Percentage of the requests served within a certain time (ms) 50 41 66 41 75 42 80 42 90 43 95 44 98 46 99 55 100 73 (longest request) siege W celu zastosowania narzędzia siege do przeprowadzenia testu porównawczego takiego sa- mego jak wyżej opisany należy użyć wiersza polecenia podobnego jak w przypadku progra- mu ab, z tym że trzeba podać liczbę generowanych żądań, które mają przypadać na jeden wątek. Jeśli w ramach testu próbuje się utworzyć 100 000 żądań HTTP z wykorzystaniem jednocześnie Pomiar wydajności serwera WWW | 147 149 klientów, trzeba poinformować narzędzie siege, że każdy z tych klientów musi utworzyć 671 żądań (ponieważ 671 żądań pomnożonych przez 149 klientów w przybliżeniu daje 100 000 żądań). Wstawienie w wierszu polecenia siege argumentu -b spowoduje, że narzędzie prze- prowadzi test porównawczy. W efekcie wątki klientów nie będą wstrzymywały pracy między kolejnymi żądaniami, jak to ma miejsce w przypadku narzędzia ab. Domyślnie program siege między kolejnymi żądaniami odczekuje określony czas. Jednak w trybie testu porównawczego tak nie jest. Przykład 4.3 prezentuje wiersz polecenia siege i wyniki testu porównawczego. Przykład 4.3. Przeprowadzenie testu porównawczego za pomocą narzędzia siege, dla którego wyłączono funkcję ciągle aktywnych połączeń $ siege -b -r 671 -c 149 host_tomcata:8080 ** siege 2.65 ** Preparing 149 concurrent users for battle. The server is now under siege.. done. Transactions: 99979 hits Availability: 100.00 Elapsed time: 46.61 secs Data transferred: 775.37 MB Response time: 0.05 secs Transaction rate: 2145.01 trans/sec Throughput: 16.64 MB/sec Concurrency: 100.62 Successful transactions: 99979 Failed transactions: 0 Longest transaction: 23.02 Shortest transaction: 0.00 Z wynikami narzędzia siege związanych jest kilka interesujących rzeczy, o których należy wspomnieć. Oto one: • Liczba transakcji zrealizowanych w ciągu sekundy przez narzędzie siege jest znacznie mniejsza niż w przypadku programu ab (jest tak, gdy dla obu klientów testujących wyłą- czono funkcję ciągle aktywnych połączeń2, a wszystkie pozostałe ustawienia są takie same). Jedynym wytłumaczeniem takiego stanu rzeczy jest to, że narzędzie siege nie jest tak efektywne, jak program ab. Na tej podstawie można wywnioskować, że wyniki testu po- równawczego narzędzia siege nie są tak dokładne, jak wyniki zwrócone przez program ab. • Przepustowość, o której informuje narzędzie siege, jest znacznie mniejsza od uzyskiwanej przez program ab. Prawdopodobnie jest to spowodowane tym, że narzędzie siege nie może przetworzyć w ciągu sekundy tak wiele żądań, jak program ab. • Podawana przez narzędzie siege całkowita ilość przesłanych danych w przybliżeniu jest równa osiągom w tym przypadku programu ab. • Program ab ukończył test porównawczy w czasie wynoszącym trochę ponad połowę czasu, jaki na to samo potrzebowało narzędzie siege. Jednak nie wiemy, ile z tego czasu narzędzie siege poświęciło na oczekiwanie między kolejnymi żądaniami każdego wątku. Może po prostu być tak, że pętla narzędzia siege obsługująca żądania nie została w takim stopniu zoptymalizowana, żeby od razu przetwarzać następne żądanie. 2 Narzędzie siege nie może przeprowadzać testu przy włączonej funkcji ciągle aktywnych połączeń. W rzeczywi- stości funkcji tej program siege jest pozbawiony (przynajmniej w czasie, gdy pisano książkę). Oznacza to, że korzystając z tego narzędzia, nie można wykonywać najbardziej intensywnych wydajnościowych testów porów- nawczych. Narzędzie umożliwia jednak przeprowadzenie innego typu testów nieobsługiwanych przez program ab. Wśród nich należy wymienić test regresji i test trybu , w którego przypadku narzędzie siege może gene- rować losowe żądania klientów, żeby dokładniej symulować rzeczywiste obciążenie witryn internetowych. 148 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat W celu uzyskania jak najlepszych wyników testów porównawczych najlepiej używać narzędzia ab zamiast siege. Jednak przy innego rodzaju testach, w których przypadku trzeba dokładnie symulować ruch sieciowy generowany przez użytkowników przeglądających strony inter- netowe, program ab nie jest odpowiedni, gdyż nie oferuje żadnej funkcji pozwalającej okre- ślić ilość czasu oczekiwania między kolejnymi żądaniami. Narzędzie siege zapewnia funkcję powodującą odczekiwanie programu losową ilość czasu między kolejnymi żądaniami. Oprócz tego narzędzie siege może pobrać losowe adresy URL z predefiniowanej listy. Z tego powo- du narzędzie siege może być użyte do symulowania obciążenia generowanego przez użyt- kownika. Czegoś takiego program ab nie umożliwia. Więcej informacji na temat funkcji na- rzędzia siege można znaleźć w jego dokumentacji (należy wykonać polecenie man siege). Apache Jakarta JMeter Narzędzie JMeter można uruchomić w trybie graficznym lub tekstowym. Choć plany testów można uaktywnić w dowolnym trybie, trzeba je utworzyć w trybie graficznym. Plany testów są przechowywane w dokumentach konfiguracyjnych XML. Jeśli w konfiguracji planu testu trzeba zmienić tylko jedną wartość numeryczną lub łańcuchową, prawdopodobnie będzie można to zrobić za pomocą edytora tekstu. Jednak z myślą o kontroli poprawności dobrym pomysłem jest edytowanie planów testów przy użyciu graficznego interfejsu narzędzia JMeter. Zanim podejmie się próbę przeprowadzenia za pomocą programu JMeter testu porównawcze- go dla serwera Tomcat, trzeba upewnić się, że wirtualną maszynę Java tego narzędzia zała- dowano z wystarczającą ilością pamięci sterty. Jest to niezbędne do uniknięcia tego, że wirtu- alna maszyna Java w trakcie wykonywania testów porównawczych przez narzędzie JMeter będzie spowalniać jego pracę przez realizowanie procesu zbierania zwolnionych obszarów pamięci. Jest to szczególnie ważne, gdy testy porównawcze przeprowadza się w trybie gra- ficznym. W skrypcie startowym bin/jmeter znajduje się ustawienie konfiguracyjne określające rozmiar pamięci sterty. Wygląda ono następująco: # Jest to podstawowy rozmiar sterty. Można go zwiększyć lub zmniejszyć odpowiednio # do ilości dostępnej pamięci systemowej: HEAP= -Xms256m -Xmx256m Narzędzie JMeter użyje całej przydzielonej mu pamięci sterty. Im więcej pamięci, tym rza- dziej konieczne będzie zbieranie zwolnionych obszarów pamięci. Jeżeli komputer z załado- wanym programem JMeter dysponuje wystarczającą ilością pamięci, zamiast obu wartości 256 powinno się ustawić większe (na przykład 512). Istotne jest, żeby zrobić to w pierwszej kolejności, ponieważ domyślna wartość tego ustawienia może zniekształcić wyniki testu po- równawczego. W celu utworzenia planu testu porównawczego należy najpierw program JMeter załadować w trybie graficznym. $ bin/jmeter Okno narzędzia JMeter po lewej stronie zawiera widok drzewa, a po prawej stronie panel ze szczegółami zaznaczonego elementu. Po wybraniu czegoś w obrębie widoku drzewa w panelu pojawią się dokładne informacje dotyczące konkretnej pozycji. Aby przeprowadzić dowolny test, wewnątrz drzewa trzeba połączyć i skonfigurować odpowiednie obiekty, a następnie narzędzie JMeter może wykonać test i przekazać wyniki. Pomiar wydajności serwera WWW | 149 W celu przygotowania testu porównawczego, takiego jak przeprowadzony za pomocą na- rzędzi ab i siege, należy wykonać następujące kroki: 1. W obrębie widoku drzewa prawym przyciskiem myszy kliknąć węzeł Test Plan i wybrać polecenie Add/Thread Group. 2. W panelu szczegółów obiektu Thread Group, w polach Number of Threads (users), Ramp-Up Period (in seconds) i Loop Count, ustawić odpowiednio wartości 149, 0 i 671. 3. Prawym przyciskiem myszy kliknąć węzeł drzewa Thread Group i z menu wybrać pole- cenie Add/Sampler/HTTP Request. 4. W panelu szczegółów obiektu HTTP Request zmienić ustawienia Web Server tak, żeby identyfikowały serwer Tomcat i numer jego portu. Dodatkowo w polu Path należy określić adres URI zasobu instalacji serwera Tomcat (na przykład katalog /), dla którego ma być przeprowadzony test porównawczy. 5. Prawym przyciskiem myszy ponownie kliknąć węzeł drzewa Thread Group i z menu wy- brać polecenie Add/Post Processors/Generate Summary Results. 6. Ze znajdującego się na samej górze menu File wybrać polecenie Save Test Plan i wprowadzić nazwę, pod jaką ma być zapisany plan testu. Rozszerzeniem pliku planu testu programu JMeter jest .jmx. Rozszerzenie to nieszczęśliwie przypomina niezwiązane z nim rozszerze- niem JMX (Java Management eXtension). Rysunek 4.1 przedstawia graficzny interfejs użytkownika narzędzia JMeter z zestawionym planem testu gotowym do uruchomienia. Widok drzewa znajduje się z lewej strony, a panel szczegółów z prawej. Rysunek 4.1. Graficzny interfejs użytkownika narzędzia Apache JMeter z kompletnym planem testu 150 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat Po utworzeniu i zapisaniu planu testu można rozpocząć test porównawczy. Z menu rozwija- nego File należy wybrać polecenie Exit, żeby zamknąć graficzny interfejs narzędzia JMeter. Dalej należy je załadować w trybie tekstowym wiersza poleceń, żeby przeprowadzić test po- równawczy. $ bin/jmeter -n -t test-strony-domowej-tc.jmx Created the tree successfully Starting the test Generate Summary Results = 99979 in 71.0s = 1408.8/s Avg: 38 Min: 0 Max: 25445 Err: 0 (0.00 ) Tidying up ... ... end of run Warto zauważyć, że liczba żądań na sekundę podana przez narzędzie JMeter (średnia liczba żądań w ciągu sekundy wynosi 1408,8) jest znacznie mniejsza od raportowanej zarówno przez program ab, jak i siege (w przypadku tej samej konfiguracji sprzętowej, identycznej wersji Tomcata i testu porównawczego). Pokazuje to, że klient HTTP narzędzia JMeter jest wolniejszy od klientów programów ab i siege. Za pomocą narzędzia JMeter można stwierdzić, czy zmiana dokonana w aplikacji WWW, instalacji serwera Tomcat lub wirtualnej maszynie Java skróciła czy wydłużyła czas odpowiedzi witryn internetowych. Jednak nie można zasto- sować narzędzia JMeter do określenia maksymalnej liczby żądań na sekundę, które serwer może z powodzeniem obsłużyć, ponieważ klient HTTP programu okazuje się wolniejszy od kodu serwera Tomcat. W przypadku narzędzia JMeter można też wyniki testu zaprezentować na wykresie. W tym celu ponownie należy załadować program w trybie graficznym, po czym wykonać następu- jące kroki: 1. Otworzyć wcześniej utworzony plan testu. 2. W obrębie widoku drzewa zaznaczyć węzeł Generate Summary Results i usunąć go (prosta umożliwiająca to metoda polega na jednokrotnym wciśnięciu klawisza Delete). 3. Zaznaczyć węzeł drzewa Thread Group, a następnie kliknąć go prawym przyciskiem my- szy i z menu wybrać polecenie Add/Listener/Graph Results. 4. Zapisać plan testu pod nową nazwą (tym razem w celu obejrzenia wyników testu w po- staci graficznej). 5. Zaznaczyć węzeł drzewa Graph Results. Można ponownie przeprowadzić test i w czasie rzeczywistym obserwować jak narzędzie JMeter wyświetla wyniki na wykresie. Ponownie trzeba sprawdzić, czy wirtualnej maszynie Java narzędzia JMeter przy- dzielono wystarczającą ilość pamięci sterty, żeby w czasie trwania testu nie prze- prowadzała często procesu zbierania zwolnionych obszarów pamięci. Ponadto trze- ba pamiętać o tym, że wirtualna maszyna Java w czasie wykonywania testu musi poświęcić czas na generowanie wykresu. Na skutek tego zmniejszy się dokładność wyników testu. To, o ile spadnie dokładność, zależy od szybkości komputera z zała- dowanym narzędziem JMeter (im szybszy, tym lepiej). Jeśli jednak wykres jest ry- sowany tylko w celu obserwacji w czasie rzeczywistym wyników przeprowadzanego testu, jest to znakomity sposób umożliwiający to. Gdy jest się gotowym do uruchomienia testu, z umieszczonego na samej górze okna menu rozwijanego Run należy wybrać polecenie Start lub wcisnąć kombinację klawiszy Ctrl+R. Pomiar wydajności serwera WWW | 151 Choć test porównawczy zostanie ponownie rozpoczęty, wyniki pokazywane na wykresie pojawią się, gdy dane wyjściowe zostaną zebrane przez narzędzie JMeter. Rysunek 4.2 poka- zuje wykres z wynikami testu wyświetlony w graficznym interfejsie narzędzia JMeter. Rysunek 4.2. Wyświetlanie wyników testu na wykresie generowanym przez narzędzie Apache JMeter Można zezwolić na dokończenie testu lub zatrzymać go przez wciśnięcie kombinacji klawi- szy Ctrl+. (przy wciśniętym klawiszu Ctrl należy wcisnąć klawisz kropki). Jeśli test zostanie przerwany w początkowej fazie, prawdopodobnie narzędziu JMeter kilka sekund zajmie jego zakończenie i usunięcie wszystkich wątków znajdujących się w obiekcie Thread Group. Aby wyczyścić wykres przed ponownym uruchomieniem testu, należy wcisnąć kombinację klawiszy Ctrl+E. Można też usunąć wykres w trakcie trwania testu. W tym przypadku test będzie kontynuowany, a wykres rysowany, począwszy od bieżącej próbki. Przez zastosowanie narzędzia JMeter do wyświetlania wyników na wykresie uzyskuje się wgląd do uruchomionego testu. Dzięki temu można go obserwować i usunąć wszelkie zaist- niałe problemy, a także dostosować test do własnych wymagań przed wywołaniem go z po- ziomu wiersza poleceń. Po uznaniu, że test został poprawnie przygotowany, należy zapisać jego plan, który nie zawiera węzła drzewa Graph Results, lecz uwzględnia węzeł Generate Summary Results, umożliwiający wywołanie testu z poziomu wiersza poleceń. Plan testu na- leży ponownie zapisać pod nową nazwą, opisującą rodzaj testu uruchamianego z poziomu wiersza poleceń. Jako ostateczne wyniki testu należy zastosować wyniki uzyskane z poziomu wiersza poleceń. Narzędzie testujące ab zapewnia dokładniejsze wyniki testu porównawcze- go, lecz nie oferuje tak wielu funkcji jak program JMeter. Narzędzie JMeter dysponuje też znacznie większą liczbą funkcji, które mogą pomóc testować aplikacje WWW na kilka sposobów. Więcej informacji o tym znakomitym narzędziu testują- cym można znaleźć w dokumentacji sieciowej (http://jakarta.apache.org/jmeter). 152 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat Porównanie wydajności serwerów WWW Wcześniej w rozdziale omówiono kilka klientów HTTP przeprowadzających testy porów- nawcze. W tym punkcie przedstawimy praktyczny przykład dotyczący serwera Tomcat, który od początku do końca demonstruje procedurę przeprowadzania testu porównawczego, a także przekazuje informacje mogące pomóc skonfigurować Tomcata tak, żeby oferował aplikacji WWW lepszą wydajność. Testy porównawcze wykonaliśmy dla wszystkich implementacji serwera WWW Tomcata, a także niezależnego serwera httpd Apache i jego modułów, które łączą się z Tomcatem w celu ustalenia, jak efektywna jest każda konfiguracja w przypadku udostępniania statycznej za- wartości. Czy serwer httpd Apache jest szybszy niż serwer Tomcat? Jaka jest najszybsza imple- mentacja złącza serwera WWW Tomcata? Jaka jest najszybsza implementacja złącza serwera wykorzystującego protokół AJP (Apache JServe Protocol)? O ile każdy z serwerów jest szybszy lub wolniejszy? Odpowiemy na te pytania, testując różne konfiguracje (przynajmniej dla jed- nej kombinacji sprzętu, systemu operacyjnego i środowiska Java). Ponieważ wyniki testu porównawczego w dużej mierze zależą od sprzętu, na którym go przeprowadzono, i od wersji całego użytego wtedy oprogramowania, mogą i będą się one zmieniać z upływem czasu. Wynika to stąd, że nowe urządzenia się różnią, nowe wersje każdego pakietu oprogramowania są inne, a także zmieniają się charakte- rystyki wydajnościowe różnych kombinacji sprzętu i (lub) oprogramowania. Po- nadto ustawienia konfiguracyjne zastosowane w teście porównawczym mają znacz- ny wpływ na uzyskiwane wyniki. Gdy Czytelnik będzie to czytał, prawdopodobnie poniższe rezultaty będą zdezaktualizowane. Jeśli nawet książka zostanie przeczytana wkrótce po wprowadzeniu jej do sprzedaży, zastosowane przez Czytelnika urządzenia i oprogramowanie raczej nie będą takie same jak wykorzystane przez nas. Jedyną metodą pozwalającą faktycznie stwierdzić, jak na komputerze będzie działać serwer Tomcat i (lub) serwer httpd Apache, jest przeprowadzenie we własnym zakresie testu porównawczego zgodnie z poniższą procedurą testową. Złącza Tomcata i moduły złącza serwera httpd Apache Serwer Tomcat oferuje implementacje trzech różnych rozwiązań serwerowych obsługujących żądania HTTP, a także implementacje tych samych trzech mechanizmów przetwarzających żądania AJP. JIO (java.io) Jest to domyślna implementacja złącza serwera Tomcat, jeśli podczas jego ładowania nie zostanie znaleziona biblioteka libtcnative elementu Connector biblioteki APR. Implementa- cja jest też znana pod nazwą Coyote. Ta serwerowa implementacja gniazd TCP utworzona w czystym języku Java korzysta z podstawowych klas sieciowych Java o nazwie java.io. Jest to implementacja zarówno protokołu HTTP, jak i AJP z funkcją pełnego blokowania. Fakt, że napisano ją w czystym języku Java, sprawia, że na poziomie binarnym można ją przenieść do wszystkich systemów operacyjnych w pełni obsługujących środowisko Java. Wiele osób jest przekonanych, że ta implementacja będzie wolniejsza od serwera httpd Apache, głównie dlatego, że utworzono ją w języku Java. Przyjmuje się, że aplikacja Java zawsze jest wolniejsza od skompilowanej w języku C. Czy tak naprawdę jest? Spraw- dzimy to. Pomiar wydajności serwera WWW | 153 APR (Apache Portable Runtime) Jest to domyślna implementacja złącza serwera Tomcat, gdy zainstaluje się go w systemie Windows za pomocą narzędzia NSIS. Jednak nie jest tak w przypadku większości innych instalacji Tomcata. Implementacja ta ma postać kilku klas Java uwzględniających skład- nik JNI, opakowujący niewielką bibliotekę libtcnative, napisaną w języku programowania C, która jest zależna od biblioteki APR. Serwer WWW httpd Apache również jest imple- mentowany w języku C i na potrzeby własnej komunikacji sieciowej wykorzystuje bibliote- kę ARP. Jednym z zadań tej alternatywnej implementacji jest zapewnienie serwerowego rozwiązania używającego tego samego udostępnionego kodu źródłowego języka C co serwer httpd Apache. Ma to na celu zdystansowanie złącza JIO, a także zaoferowanie wy- dajności, która przynajmniej dorównuje osiągom serwera httpd Apache. Wadą imple- mentacji APR jest to, że ponieważ przede wszystkim napisano ją w języku C, jedna binarna wersja tego elementu Connector nie zostanie zastosowana w przypadku wszystkich plat- form obsługiwanych przez złącze JIO. Oznacza to, że administratorzy Tomcata muszą bu- dować złącze APR. W związku z tym wymagane jest środowisko programowania, a ponadto mogą wystąpić problemy z procesem budowania. Jednak twórcy tej wersji elementu Connector uzasadniają dodatkowe czynności przygotowawcze tym, że wydajność serwera WWW Tomcata będzie większa, gdy się ją zastosuje. Sami się o tym przekonamy, prze- prowadzając testy porównawcze. NIO (java.nio) Jest to alternatywna implementacja elementu Connector napisana w czystym języku Java, która używa podstawowych klas sieciowych Java o nazwie java.nio, oferujących funkcje gniazd TCP bez blokowania. Głównym zadaniem tej implementacji elementu Connector jest zapewnienie administratorom Tomcata rozwiązania, które funkcjonuje efektywniej od złącza JIO. W przypadku tej implementacji użyto mniejszej liczby wątków przez zre- zygnowanie z blokowania dla wybranych składników złącza. Fakt blokowania przez złą- cze JIO odczytów i zapisów oznacza, że jeśli administrator skonfiguruje złącze pod kątem jednoczesnej obsługi 400 połączeń, będzie ono musiało wywołać 400 wątków środowiska Java. Z kolei złącze NIO wymaga tylko jednego wątku do przetwarzania żądań wielu połączeń. Jednak później każde żądanie skierowane do serwletu musi dysponować wła- snym wątkiem (ograniczenie narzucone przez specyfikację Java Servlet Specification). Ponieważ część obsługi żądania ma miejsce w kodzie Java bez blokowania, w czasie wymaganym na zrealizowanie tego zadania wątek Java nie musi być używany. Oznacza to, że do obsługi tej samej liczby jednoczesnych żądań może być wykorzystana mniejsza pula wątków. Zwykle wiąże się z tym mniejsze obciążenie procesora, a to z kolei powo- duje wzrost wydajności. Teoria wyjaśniająca, dlaczego coś takiego przyczyni się do zwiększenia wydajności, opiera się na sporym zestawie założeń, które mogą (lub nie) doty- czyć aplikacji WWW i ruchu sieciowego generowanego przez dowolną osobę. Dla części osób złącze NIO będzie działać lepiej, a dla części gorzej (tak też jest w przypadku innych implementacji złączy). Oprócz tych złączy serwera Tomcat przetestowaliśmy serwer httpd Apache w konfiguracjach Prefork i Worker modelu MPM (Multi-Process Model), w przypadku których testowe żądania były wysyłane z serwera httpd Apache do serwera Tomcata za pośrednictwem modułu złącza tego pierwszego. Test porównawczy wykonaliśmy dla następujących modułów złączy serwera httpd Apache: 154 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat mod_jk Moduł ten jest rozwijany w ramach projektu serwera Apache Tomcat. Projekt ten rozpoczęto wiele lat przed dodaniem do modułu mod_proxy serwera httpd Apache obsługi protokołu AJP (złącza AJP Tomcata implementują protokół po stronie serwera). Moduł mod_jk jest modułem serwera httpd Apache, który implementuje protokół AJP po stronie klienta. Jest to binarny protokół bazujący na pakietach TCP, którego zadaniem jest przekazywanie zawartości żądań HTTP do instancji innego serwera znacznie szybciej niż byłoby to możliwe w przypadku samego protokołu HTTP. Założenie jest takie, że protokół HTTP jest w dużym stopniu ukierunkowany na przesyłanie zwykłego tekstu, a zatem po serwerowej stronie połą- czenia wymaga wolniejszych i bardziej złożonych analizatorów. Jeśli zamiast protokołu HTTP zastosuje się binarny protokół przekazujący poddane już analizie łańcuchy tekstowe żądań, serwer może odpowiedzieć znacznie szybciej, a ponadto może być zminimalizo- wane obciążenie wywołane przez komunikację sieciową. Taka przynajmniej jest teoria. Przekonamy się, jak bardzo różni się to w praktyce. Gdy pisano książkę, większość użytkow- ników serwera httpd Apache dodających Tomcata do swoich serwerów WWW w celu ob- sługi serwletów i (lub) stron JSP budowała moduł mod_jk i korzystała z niego głównie dla- tego, że była przekonana, że jest on znacznie szybszy od modułu mod_proxy, bądź dlatego, że nie miała świadomości, że moduł mod_proxy jest prostszą alternatywą. Innym powo- dem takiego stanu rzeczy było to, że ktoś zaproponował takim użytkownikom zastoso- wanie modułu mod_jk. Postanowiliśmy sprawdzić, czy budowanie, instalowanie, konfi- gurowanie i utrzymywanie modułu mod_jk jest warte uzyskanej wydajności. mod_proxy_ajp Jest to odmiana modułu mod_proxy, która obsługuje złącze protokołu AJP. Moduł mod_ (cid:180)proxy_ajp łączy się z portem protokołu AJP serwera Tomcat za pośrednictwem protokołu TCP, wysyła żądania do Tomcata, oczekuje na jego odpowiedzi, a następnie serwer httpd Apache przekazuje je do klientów WWW. Żądania w dwóch kierunkach są przesyłane między serwerami httpd Apache i Tomcat. Tak jak w przypadku modułu mod_jk między tymi serwerami pośredniczy protokół AJP. Złącze tego protokołu stało się częścią serwera httpd Apache, począwszy od wersji 2.2, i aktualnie wchodzi w skład serwera Apache do- łączanego do większości systemów operacyjnych lub jest domyślnie dodawane w postaci ładowalnego modułu serwera httpd. W celu użycia złącza zwykle nie jest konieczna żadna dodatkowa kompilacja lub instalacja. Wystarczy skonfigurować serwer httpd Apache. Po- nieważ moduł mod_proxy_ajp bazuje na module mod_jk, kod i funkcje obu tych modułów są do siebie bardzo podobne. mod_proxy_http Jest to odmiana modułu mod_proxy, która obsługuje złącze protokołu HTTP. Podobnie do modułu mod_proxy_ajp, moduł ten łączy się z Tomcatem za pośrednictwem protokołu TCP, lecz w celu nawiązania połączenia z portem HTTP serwera WWW Tomcata. Oto proste przedstawienie sposobu działania modułu mod_proxy_http — klient WWW wysyła żądanie do serwera httpd Apache, a ten następnie to samo żądanie kieruje do serwera WWW Tom- cata, który odpowiada serwerowi httpd, a ten odpowiedź przekazuje klientowi WWW. Gdy używa się modułu mod_proxy_http, cała komunikacja między serwerami httpd Apache i Tomcat jest realizowana za pomocą protokołu HTTP. Również moduł złącza protokołu HTTP wchodzi w skład serwera httpd Apache. Zazwyczaj moduł mod_proxy_http jest czę- ścią binariów serwera httpd, dołączonych do większości systemów operacyjnych. Ponie- waż moduł od bardzo dawna jest elementem serwera httpd Apache, jest dostępny nieza- leżnie od jego zastosowanej wersji. Pomiar wydajności serwera WWW | 155 Konfiguracje sprzętowe i programowe wykorzystane w testach porównawczych Do testowania działającego oprogramowania wybraliśmy dwie różnego typu serwerowe platformy sprzętowe. Poniżej zamieszczono opis dwóch komputerów, które posłużyły do przeprowadzenia testów porównawczych. Komputer stacjonarny: dwa procesory Intel Xeon 64 2,8 GHz, pamięć RAM 4 GB, dysk twardy SATA 160 GB o prędkości 7200 obrotów na minutę. Jest to komputer w obudowie typu Tower z dwoma 64-bitowymi procesorami Intela, z któ- rych każdy wyposażono w jeden rdzeń i technologię hiperwątkowości. Laptop: procesor AMD Turion64 ML-40 2,2 GHz, pamięć RAM 2 GB, dysk twardy IDE 80 GB o prędkości 5400 obrotów na minutę. Jest to laptop z pojedynczym 64-bitowym jednordzeniowym procesorem AMD. Ponieważ jeden z komputerów jest stacjonarny, a drugi to laptop, wyniki testów pokażą również różnice w możliwości udostępniania statycznych plików przez jedno- i dwuprocesorowy kom- puter. Nie próbowaliśmy dopasowywać dwóch odmiennych modeli procesorów pod względem podobnej mocy obliczeniowej, lecz testom porównawczym poddaliśmy typowy 2-procesorowy komputer stacjonarny i 1-procesorowy laptop, które w czasie przeprowadzania testów były nowością na rynku. Oba komputery na dyskach twardych mają zwykłe partycje ext3. Z tego względu w testach porównawczych nie wykorzystano żadnych konfiguracji LVM lub RAID. Choć oba komputery bazują na architekturze x86_64, ich procesory zostały zaprojektowane i wyprodukowane przez różne firmy. Ponadto komputery te wyposażono w kartę sieciową Gigabit Ethernet i testowano je z innego komputera, również dysponującego taką samą kartą. Komputery podłączono do przełącznika sieciowego obsługującego technologię Gigabit Et- hernet. Zdecydowaliśmy się zastosować klienta testującego ApacheBench (ab). Zależało nam na zapew- nieniu obsługi przez klienta funkcji ciągle aktywnych połączeń HTTP 1.1, ponieważ właśnie ją chcieliśmy poddać testom. Poza tym oczekiwaliśmy, że klient będzie na tyle szybki, że wy- generuje jak najbardziej dokładne wyniki. Zapoznaliśmy się z artykułem zamieszczonym na blogu przez Scotta Oaksa (http://weblogs.java.net/blog/sdo/archive/2007/03/ab_considered_h.html). Choć zgadzamy się z analizą działania narzędzia ab dokonaną przez Oaksa, dokładnie monito- rowaliśmy obciążenie procesora przez klienta testującego ab i zyskaliśmy pewność, że w czasie wykonywanych testów nigdy nie przeciążył wykorzystywanego procesora. Dodatkowo dla narzędzia ab uaktywniliśmy funkcję, która pozwala na jednoczesną aktywność więcej niż jednego żądania HTTP. Fakt, że pojedynczy proces narzędzia ab może używać dokładnie jednego procesora nie stanowi problemu, gdyż system operacyjny przełącza konteksty w pro- cesorze szybciej, niż sieć jest w stanie wysyłać i odbierać żądania, a także pakiety odpowiedzi. Okazuje się, że dla procesora w rzeczywistości wszystko jest pojedynczym strumieniem in- strukcji sprzętowych. Ponieważ podczas przeprowadzanych przez nas testów komputer ser- wera WWW nie dysponował wystarczającą liczbą rdzeni procesora, żeby przeciążyć procesor komputera z uruchomionym narzędziem ab, w rzeczywistości mierzyliśmy wydajność same- go serwera WWW. Testom poddaliśmy serwer Tomcat 6.0.1 (gdy rozpoczynaliśmy testy, była to najnowsza do- stępna wersja; spodziewamy się, że nowsze wersje będą szybsze, lecz do momentu wykona- nia testu nigdy nie można być tego pewnym) załadowany w środowisku Sun Java 1.6.0 GA przeznaczonym dla platformy x86_64. Dodatkowo testowaliśmy serwer Apache 2.2.3, moduł 156 | Rozdział 4. Optymalizowanie wydajności serwera Tomcat mod_jk wchodzący w skład oprogramowania Tomcat Connectors (wersja 1.2.20) i złącze bi- blioteki APR (libtcnative) w wersji 1.1.6. W czasie przeprowadzania testów były to najnowsze wersje oprogramowania. Przykro nam, że na potrzeby książki nie mogliśmy przetestować nowszych wersji. Jednak znakomitą rzeczą związaną ze szczegółowo opisanymi testami jest to, że zapewniają ilość informacji wystarczającą do powtórzenia ich we własnym zakresie. Na obu komputerach zainstalowano system operacyjny Fedora Core 6 Linux x86_64 z aktualiza- cjami dokonanymi za pomocą narzędzia yum. Użyto jądra w wersji 2.6.18.2. Oto zastosowane ustawienia startowych parametrów wirtualnej maszyny Java serwera Tomcat: -Xms384M -Xmx384M -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true Konfiguracja serwera Tomcat wykorzystana na potrzeby testów uwzględnia plik conf/web.xml, plik conf/server.xml (z tym że nie włączono rejestratora prób dostępu; w efekcie nie będą reje- strowane informacje dla poszczególnych żądań), a także poniższe konfiguracje złączy, z któ- rych dla różnych testów w danej chwili było stosowane tylko jedno. !-- Złącze JIO HTTP -- Connector port= 8080 protocol= HTTP/1.1 maxThreads= 150 connectionTimeout= 20000 redirectPort= 8443 / !-- Złącze APR HTTP -- Connector port= 8080 protocol= org.apache.coyote.http11.Http11AprProtocol enableLookups= false redirectPort= 8443 connectionTimeout= 20000 / !-- Złącze NIO HTTP -- Connector port= 8080 maxThreads= 150 connectionTimeout= 20000 redirectPort= 8443 protocol= org.apache.coyote.http11.Http11NioProtocol / !-- Złącze JIO/APR AJP modyfikowane przez ustawienie LD_LIBRARY_PATH -- Connector port= 8009 protocol= AJP/1.3 redirectPort= 8443 / !-- Złącze NIO AJP -- Connector protocol= AJP/1.3 port= 0 channelNioSocket.port= 8009 channelNioSocket.maxThreads= 150 channelNioSocket.maxSpareThreads= 50 channelNioSocket.minSpareThreads= 25 channelNioSocket.bufferSize= 16384 / Kod biblioteki APR został uaktywniony za pomocą przedstawionej konfiguracji złącza APR HTTP, a także przez ustawienie katalogu zawierającego bibliotekę libtcnative dla zmiennej środowiskowej LD_LIBRARY_PATH procesu wirtualnej maszyny Java Tomcata i wyeksportowa- nie jej, a następnie zrestartowanie serwera Tomcat. Złącze APR jest budowane w następujący sposób: # CFLAGS= -O3 -falign-functions=0 -march=athlon64 -mfpmath=sse -mmmx -msse -msse2 - msse3 -m3dnow -mtune=athlon64 ./configure --with-apr=/usr/bin/apr-1-config -- prefix=/opt/tomcat/apr-connector # make make install Przeprowadzając proces budowania serwera httpd Apache i modułu mod_jk, zastosowaliśmy takie same zmienne środowiskowe CFLAGS. Moduł mod_jk zbudowaliśmy i zainstalowaliśmy w następujący sposób: Pomiar wydajności serwera WWW | 157 # cd tomcat-connectors-1.2.20-src/native # CFLAGS= -O3 -falign-functions=0 -march=athlon64 -mfpmath=sse -mmmx -msse -msse2 - msse3 -m3dnow -mtune=athlon64 ./configure --with-apxs=/opt/httpd/bin/apxs [usunięto mnóstwo wynikowych danych konfiguracyjnych] # make make install Przyjęto, że główny katalog zbudowanego serwera httpd Apache identyfikuje ścieżka /opt/httpd. Proces budowania złącza APR, serwera httpd i modułu mod_jk zrealizowano za pomocą narzę- dzia GCC 4.1.1. # gcc --version gcc (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Z witryny o adresie http://httpd.apache.org pobraliśmy serwer httpd Apache w wersji 2.2.3, a na- stępnie zbudowaliśmy go na dwa różne sposoby i przetestowaliśmy każde z uzyskanych bi- nariów. Proces budowania został przeprowadzony dla konfiguracji Prefork i Worker modelu MPM. Są to różne odmiany modelu wielowątkowego i wieloprocesowego, z których serwer może korzystać. Oto ustawienia użyte dla konfiguracji Prefork i Worker modelu MPM: # Prefork MPM IfModule prefork.c StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 /IfModule # Worker MPM IfModule worker.c StartServers 3 MaxClients 192 MinSpareThreads 1 MaxSpareThreads 64 ThreadsPerChild 64 MaxRequestsPerChild 0 /IfModule Dla serwera httpd Apache wyłączyliśmy rejestrowanie zwykłego dostępu, żeby w dzienniku nie musiało być nic zapisywane dla każdego żądania (tak samo skonfigurowaliśmy Tomcata). Uaktywniliśmy opcję konfiguracyjną KeepAlive serwera httpd Apache. KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 5 Przy użyciu jednej z dwóch metod uaktywniliśmy moduł mod_proxy. Najpierw włączyliśmy usługę proxy za pośrednictwem protokołu HTTP. Oto wiersze uaktywniające usługę proxy za pośrednictwem protokołu AJP: ProxyPass /tc ajp://127.0.0.1:8009/ ProxyPassReverse /tc ajp://127.0.0.1:8009/ Skonfigurowaliśmy moduł mod_jk przez dodanie do pliku httpd.conf następujących wierszy: LoadModule jk_module /opt/httpd/module
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Tomcat. Przewodnik encyklopedyczny. Wydanie II
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: