Współczesne serwery WWW powinny szybko i pewnie dostarczać dynamiczną zawartość, która w wielu przypadkach jest pobierana z zewnętrznych baz danych. Liczy się przy tym wydajność sprzętu i systemu operacyjnego serwera, a także oprogramowania serwera i aplikacji WWW, interfejsów z bazą danych oraz odpowiednich zabezpieczeń.

W celu przeprowadzenia testu każdy z producentów określił właściwe ustawienia konfiguracyjne. Realizowano te zalecenia, pod warunkiem że odzwierciedlały one praktyczne implementacje. Dostrojenie pozwalające uzyskać maksymalną wydajność wymagało ogromnej cierpliwości, ponieważ trzeba było optymalizować każdą z części składowych. Postanowiono nie oceniać wydajności, ponieważ nie można było uruchomić pełnego testu wzorcowego, który pozwoliłby określić, jak powinien działać współczesny serwer WWW. Wyniki testu wydajności dotyczą jedynie obsługi adresów i grafiki, a uzyskano je w teście Intermark 1.0 firmy Client/Ser- ver Labs. Nie obejmują one zadań serwera bazy danych.

Z wyjątkiem jednego przypadku, wszystkie serwery mają wystarczającą moc. Producenci dostarczyli dużo pamięci RAM (256 MB) i szybkie podsystemy dyskowe. Każdy serwer miał od 2 GB do 16 GB wolnego miejsca na dysku. Wszystkie, z wyjątkiem rozwiązania Apache, wykorzystywały podsystem RAID 5.

Najsłabszym rozwiązaniem okazał się dwuprocesorowy 2000P z procesorem Pentium Pro 200 MHz. Aby przeprowadzić test, trzeba było wyłączyć obsługę drugiego procesora. Tylko ten system nie zdołał ukończyć wszystkich testów. Podczas pierwszej próby serwer zawiesił się po ok. minucie od uruchomienia testu. Zdaniem obsługi technicznej Red Hat Software, przyczyną były błędy w jądrze systemu, związane z obsługą systemów wieloprocesorowych.

Strojenie

Trudno jednoznacznie określić wymagania serwera, nie biorąc jednocześnie pod uwagę systemu operacyjnego. Testowano serwery WWW, działające w systemach Linux, AIX i Windows NT. Z testów wydajności wynika, że tylko serwer ICSS IBM, działający w systemie AIX, ma niemal idealną wydajność.

Aby dostroić system NT, zwiększono do maksimum przepustowość serwera aplikacji i wyłączono określone usługi serwera, takie jak spooler, plug and play, alerter, messenger oraz TCP/IP NetBIOS. W systemie AIX zwiększono rozmiar kolejki oraz bufora nadawczego TCP/IP.

Na poziomie aplikacji strojenie testowanych serwerów WWW było proste. W IIS wydłużono czas przechowywania obiektów w pamięci podręcznej i rozmiar dziennika oraz przeniesiono dzienniki na oddzielny dysk. W ICSS wyłączono dziennik agenta, w którym zapisywane są informacje o przeglądarkach odczytujących strony. Wyłączono również dziennik odsyłania, w którym zapisywane są adresy stron, pozwalające użytkownikowi dotrzeć na żądaną stronę. Ponadto zwiększono maksymalną liczbę aktywnych wątków ICSS. Dla Netscape'a zwiększono liczbę żądań obsługiwanych jednocześnie i wyłączono statystykę SNMP oraz udostępnianie zasobów i agentów. W przypadku Lotus Notes zwiększono maksymalną liczbę wątków i usunięto z pliku Notes.ini kilka zadań serwera.

Problemy z testem

Skrypty CGI umożliwiły odejście od statycznych stron WWW w kierunku integracji z bazami danych lub dynamicznego generowania zawartości. Jednak każde wywołanie CGI wymaga oddzielnego procesu na serwerze. Duży program CGI napisany w C++ z pewnością znacznie obciąży, bądź zablokuje, serwer.

Ponadto obsługa CGI wiąże się ze znacznymi narzutami, występującymi przy łączeniu się z bazą danych. CGI umożliwia stworzenie tylko jednego połączenia z bazą danych dla danego klienta. Jest ono zamykane po odebraniu danych z bazy.

Mając na uwadze wydajność, większość programistów korzysta obecnie z interfejsów programowania, takich jak Internet Connection (ICAPI) firmy IBM, Internet Server (ISAPI) Microsoftu czy Netscape Server (NSAPI) Netscape'a. Interfejsy programowania są wykonywane w procesie i dlatego nie wprowadzają narzutów, takich jak CGI. Natomiast ich największą wadą jest brak wspólnego standardu. Wiele problemów wynikało właśnie z tego faktu.

Opracowanie interfejsu programowania dla każdego serwera WWW okazało się zadaniem trudnym i czasochłonnym i zakończyło się niepowodzeniem, mimo pomocy producentów. Pojawiły się też problemy z serwerem IIS i napisanym kodem ISAPI. Jego zadaniem miało być połączenie IIS-a z serwerem bazy danych Oracle'a, działającym na komputerze AlphaServer 4100 firmy Digital.

Komunikacja serwera WWW z serwerem bazy danych nie była prosta i bezpośrednia. Zasadniczo przebiegała ona od serwera IIS do biblioteki DLL ISAPI, następnie do programu obsługi łącza ODBC, programu obsługi Oracle SQLNet i bazy danych Oracle'a. Właśnie tu występowały błędy wielu połączeń z naszą bazą danych. Natomiast przejście do pojedynczego połączenia było nie do zaakceptowania.

Przy współpracy z Microsoftem próbowano różnych programów obsługi, uzyskano informacje o poolingu ODBC, uruchomiono nawet inną wersję programu serwera IIS, która ładowała wstępnie programy obsługi SQLNet. Pracownicy Microsoftu twierdzą, iż nie udało im się odtworzyć powstałego podczas testu błędu i że nawiązywali między serwerem IIS a bazą Oracle'a połączenia wielokrotne o dużym obciążeniu.

Firma Netscape pomogła w stworzeniu testu wzorcowego. Udostępniła szablon wywoływania bibliotek DLL Oracle Call Interface.

Po kilku nieudanych próbach uruchomienia Enterprise Servera, zrezygnowano ze względu na zbliżający się termin końcowy. Ponadto, z uwagi na ograniczenia czasowe, nie próbowano uruchomić testu na serwerze ICSS z ICAPI firmy IBM, a także na serwerze Apache z Fast CGI.