Jason Brittain, ebooki
[ Pobierz całość w formacie PDF ]
4.
Optymalizowanie wydajności serwera Tomcat ........................................................141
Pomiar wydajności serwera WWW
142
Zewnętrzne dostrajanie
167
Wewnętrzne dostrajanie
170
Planowanie obciążenia
178
Dodatkowe źródła informacji
181
5.
Integracja z serwerem WWW Apache ...................................................................... 183
Zalety i wady integracji
184
Instalowanie serwera httpd Apache
189
Integrowanie serwera Apache z Tomcatem
191
6.
Zabezpieczenia serwera Tomcat .............................................................................. 215
Zabezpieczanie systemu
216
Wiele modeli zabezpieczeń serwera
218
Zastosowanie narzędzia SecurityManager
219
Nadawanie uprawnień do plików
223
Tworzenie „klatki” narzędzia chroot Tomcata
227
Odfiltrowywanie danych wprowadzonych
przez użytkownika ze złymi zamiarami
237
Zabezpieczanie serwera Tomcat za pomocą protokołu SSL
255
7.
Konfiguracja ................................................................................................................271
Plik server.xml
272
Plik web.xml
329
Plik tomcat-users.xml
345
Plik catalina.policy
346
Plik catalina.properties
346
Plik context.xml
348
8.
Rozwiązywanie problemów i debugowanie ...........................................................349
Analizowanie plików dzienników
349
Szukanie błędów
350
Adresy URL i komunikacja HTTP
351
Debugowanie za pomocą narzędzia RequestDumperValve
355
Gdy nie udaje się wyłączyć serwera Tomcat
356
9.
Tworzenie binariów serwera Tomcat z kodu źródłowego ...................................... 361
Instalowanie oprogramowania Apache Ant
362
Uzyskiwanie kodu źródłowego
363
Pobieranie dodatkowych bibliotek
365
Budowanie serwera Tomcat
366
6
|
Spis treści
10.
Klaster węzłów z serwerem Tomcat ........................................................................369
Pojęcia związane z klastrem
370
Proces komunikacji związany z żądaniem HTTP
371
Rozproszone kontenery serwletów Java
381
Implementacja klastra w serwerze Tomcat 6
385
Dystrybucja żądań JDBC i przełączanie po awarii
402
Dodatkowe źródła informacji
402
11.
Podsumowanie ..........................................................................................................405
Dodatkowe zasoby
405
Społeczność
408
A
Instalowanie środowiska uruchomieniowego Java .................................................411
Wybieranie pakietu JDK
412
Radzenie sobie ze starszymi wirtualnymi maszynami Java pakietów GCJ i Kaffe
413
Sun Microsystems Java SE JDK
416
IBM J9 JDK
417
BEA JRockit JDK
418
Apple Java SE JDK
419
Excelsior JET
420
Apache Harmony JDK
423
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 odpowiedzi
1
.
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
[ Pobierz całość w formacie PDF ]