Windows Server 2003 przyśpieszenie na 64 bity

Przedstawiamy kolejny z serii testów systemu operacyjnego. Tym razem mamy na warsztacie 64-bitową edycję Windows Server 2003. Testy wykazały, że system operacyjny osiąga bardzo dobrą wydajność, kiedy wykorzystuje opcjonalne mechanizmy przetwarzania zawarte w jądrze. Jeżeli ich nie wykorzystuje, to pracuje nieco wolniej niż inne dotychczas testowane 64-bitowe systemy operacyjne.

Przedstawiamy kolejny z serii testów systemu operacyjnego. Tym razem mamy na warsztacie 64-bitową edycję Windows Server 2003. Testy wykazały, że system operacyjny osiąga bardzo dobrą wydajność, kiedy wykorzystuje opcjonalne mechanizmy przetwarzania zawarte w jądrze. Jeżeli ich nie wykorzystuje, to pracuje nieco wolniej niż inne dotychczas testowane 64-bitowe systemy operacyjne.

Windows Server 2003 przyśpieszenie na 64 bity

Opcje jądra Windows Server 2003 x64 pozwalają poszczególnym procesom pracować na poziomie kodu jądra - w przypadku testów było to przetwarzanie certyfikatów SSL, buforowanie (caching) i obsługa sesji. Kiedy połączy się te opcje z odpowiednimi 64-bitowymi sterownikami sprzętowymi i z olbrzymim rozmiarem pamięci, jaki procesor 64-bitowy może adresować, otrzymuje się najlepszą wydajność, jaką można uzyskać na architekturach Intel/AMD.

Przy włączonej opcji przetwarzania SSL na poziomie jądra, liczba obsługiwanych użytkowników wzrosła o 90% w porównaniu z 32-bitową wersją Windows Server 2003. W porównaniu z innymi 64-bitowymi systemami operacyjnymi (Red Hat Enterprise Linux 4.0 [RHEL 4.0] Advanced Server i Solaris 10), Windows Server 2003 x64 osiąga przewagę 15 do 20%.

Bez opcji przetwarzania na poziomie jądra wydajność Windows Server 2003 x64 jest trochę niższa niż konkurencyjnych 64-bitowych systemów operacyjnych (zob. NetWorld 2/2005, 4/2005 i 6/2005).

Windows Server 2003 przyśpieszenie na 64 bity

Wydajność transakcji SSL

Ujemną stroną tego wydania są problemy kompatybilności związane ze sprzętem, na jakim Windows Server 2003 x64 może pracować i aplikacjami, które może obsługiwać.

Dwa systemy AMD64 użyte do testów okazały się niekompatybilne z Windows Server 2003 x64. Jeden z nich nie potrafił uruchomić jądra. Drugi załamywał się regularnie po instalacji, co związane było z taktowaniem pamięci na płycie głównej i problemami ze sterownikami SCSI.

Systemy zapewniane przez partnerów OEM Microsoftu - Polywell i HP - nie wykazywały żadnych problemów. Podstawowym serwerem testowym był HP Opteron DL585. (Hewlett-Packard był jedynym dostawcą sprzętu zapewniającym pełny zestaw sterowników na stronie webowej Microsoftu od momentu wypuszczenia 64-bitowego systemu operacyjnego w kwietniu br.). Kupujący są więc w dużej mierze zdani na dostawców sprzętu OEM. To oczywiście zawęża wybór, a takich ograniczeń nie mają 64-bitowe edycje Solaris 10, SuSE SLES 9 czy RHEL 4.0.

Stare DOS-owe programy 16-bitowe nie pracują lub pracują niepoprawnie pod tym systemem. Przy pracy aplikacji 32-bitowych Microsoft wykorzystuje 32-bitowy emulator o nazwie WOW64, który jest wywoływany automatycznie. Podczas testów obserwowano zazwyczaj mniejszą wydajność takich aplikacji na Windows Server 2003 x64 niż na 32-bitowym Windows Server 2003.

Kody interpretowane, takie jak stare aplikacje Visual Basic, pracowały poprawnie na motorze 64-bitowym. Nie stwierdzono też żadnej różnicy czasu wykonywania skryptów Perl podczas pracy MS Internet Information Server w 32- i 64-bitowym środowisku Windows.

Wydajność

Windows Server 2003 przyśpieszenie na 64 bity

Obsługa połączeń TCP

Skrypt SSL Transaction zaprojektowano, używając oprogramowania Web Avalanche firmy Spirent Communications do pomiaru liczby ustanowionych transakcji SSL w cyklach dziesięciominutowych (zob. "Jak testowano").

Ten szczególny test polegał na zwiększaniu liczby bezpiecznych sesji użytkowników aż do momentu, kiedy liczba utraconych sesji osiągnęła 1%. Generowanie sesji SSL znacznie obciąża CPU i zarządzanie dużą liczbą sesji jest wskaźnikiem dobrej wydajności systemu operacyjnego.

Skrypt ten testowano na obu wersjach Windows: 32- i 64-bitowej, po czym porównano je z wynikami osiągniętymi przez 64-bitowe jądro 2.6.7 w RHEL 4.0 i 64-bitową edycję Solaris 10. Oba systemy obsługiwały serwer webowy Apache 2.0.3 z OpenSSL. W obu przypadkach używano domyślnych ustawień (z wyjątkiem sytuacji wykorzystania przetwarzania SSL na poziomie jądra w Windows 2003 Server x64).

Dla Windows Server 2003 x64 wykonano dwa zestawy testów pomiarowych: jeden przy domyślnych ustawieniach jądra oraz drugi przy wspomnianym wyżej przełączeniu, które dopuszczało przetwarzanie procesów SSL na poziomie jądra.

Różnica pomiędzy wynikami była istotna i potwierdzała korzyści wynikające z tego prostego ustawienia. Jeżeli sesje SSL były obsługiwane na poziomie jądra, to podczas testów przeprowadzonych na czteroprocesorowym serwerze HP DL585 system operacyjny mógł utrzymać 288 471 sesji w czasie 10 min.

Obsługa sesji SSL przez Windows Server 2003 x64 przy domyślnym ustawieniu jądra też była wydajna (207 202 sesje), ale nie tak, jak w przypadku RHEL 4.0 (251 024 sesje). Microsoft uzasadnia domyślne wyłączenie tej opcji jądra koniecznością zachowania kompatybilności wstecznej.

Dla porównania wykonano także dwa wcześniej stosowane testy - maksymalnej liczby otwartych sesji TCP, który mierzy, ile takich sesji może być ustanowionych i obsłużonych, oraz liczby sesji TCP na sekundę, jaką każdy z tych systemów może obsłużyć, określającą, jak szybko system może włączać nowe sesje.

W teście maksymalnej liczby transakcji Windows Server 2003 x64 był lepszy od RHEL 4.0, ale słabszy niż Solaris 10. W liczbie transakcji TCP na sekundę Microsoft pobił Suna, ale uległ Red Hat.

Podsumowanie

Z wierzchu nie widać istotnych różnic pomiędzy 32- a 64-bitową edycją Windows Server 2003. Jednak osiągana wydajność podkreśla zalety sprzętu i możliwości 64-bitowej adresacji. Windows Server 2003 jest wydajny, zwłaszcza kiedy wykorzystuje zalety nowych opcji jądra.

Aczkolwiek braki w sterownikach obsługujących sprzęt są na tyle poważne, że Microsoft praktycznie zmusza kupujących do korzystania z oferty dostawców OEM związanych z Microsoftem, jako źródła produktów kompatybilnych z Windows Server 2003 x64. Gdy sprawy te zostaną z biegiem czasu rozwiązane, nowy system można ze spokojem polecić, ponieważ jest on stabilny i naprawdę szybki.

Jak testowano

Kompatybilność 64-bitowego Windows Server 2003 Enterprise x64 Edition z platformami sprzętowymi testowano na czterech platformach. Nie napotkano problemów przy testowaniu kodu 64-bitowego na podstawowych platformach testowych - HP DL585 z czterema CPU AMD Opteron 2,4 GHz i 12 GB RAM. Również testy kodu 64-bitowego na serwerze Polywell 2200S z dwoma AMD Opteron 2,8 GHz i 4 GB RAM nie sprawiły żadnego kłopotu. Natomiast poważne problemy pojawiły się podczas próby uruchomienia tego kodu na składanym komputerze AMD Opteron 2,8 GHz z 1GB RAM (płyta MSI), a także AMD Opteron 2.0 GHz z 1GB RAM (płyta Asus K8N).

Oficjalne testy wydajnościowe Windows Server 2003 x64 prowadzone były na HP DL585. Testy przeprowadzono w dwóch trybach: domyślnym i z włączoną opcją obsługi SSL na poziomie jądra.

Nie stosowano żadnych innych zabiegów optymalizacyjnych. Server Windows był zarówno sterownikiem domeny Active Directory (i w związku z tym serwerem DNS), jak również pełnił rolę Certificate Authority. Obsługiwał również Internet Information Server wersji 6.0. Skonfigurowano jednego anonimowego użytkownika dla wszystkich testów weba. Podczas testów nie używano żadnego systemu równoważenia obciążeń (load balancing).

Do testów użyto ten sam serwer HP DL585, który stosowano podczas testów Solaris 10, Red Hat Advanced Server 4 i SuSE Linux Enterprise Server 9 (wszystkie na ustawieniach domyślnych) oraz Apache 2.0.3 z OpenSSL 9 (zob. NetWorld 2/2005, 4/2005 i 6/2005). Aktywny był DNS, ale nie używano LDAP, SAMBA i proxy SQUID.

Wydajność testowano, używając dwóch systemów Spirent Web Avalanche pracujących równolegle.

Przy testach SSL systemy Web Avalanche połączono przez trzy połączenia Gigabit Ethernet: dwa do jednego z systemów Web Avalanche i jedno do drugiego.

Test SSL budował zestaw sesji SSL poprzez połączenia HTTPS czytające z testowanego serwera do momentu, aż liczba współbieżnych użytkowników osiągnęła punkt nasycenia (generując 1% błędów), który określono jako maksymalną liczbę sesji współbieżnych. Test zaprojektowano do ćwiczenia usług webowych i efektywności systemu operacyjnego, aż do uzyskania pełnego nasycenia. Czas trwania testu zaplanowano na 10 min, ale nasycenie pojawiało się wcześniej.

Wykonano także testy TCP Open Connection i TCP Maximum Connection dla celów porównawczych z testami innych systemów operacyjnych.

Test TCP Open Connection służy do oceny liczby sesji TCP, jaką można osiągnąć w czasie sekundy. Z kolei test TCP Maximum Connection mierzy liczbę otwartych połączeń TCP, które mogą być ustanowione do momentu, aż stopa błędów przekroczy 5% (połączeń nieobsłużonych).


TOP 200