Budowanie w górę

Choć 64-bitowe Windows 2003 i SQL Server 2000 wyrastają wysoko ponad platformę 32-bitową, po drodze brak im kilku pięter.

Choć 64-bitowe Windows 2003 i SQL Server 2000 wyrastają wysoko ponad platformę 32-bitową, po drodze brak im kilku pięter.

To proste, naprawdę - większe jest lepsze. W porównaniu z systemem 32-bitowym system 64-bitowy oferuje większą przestrzeń adresową na aplikacje, szerszą magistralę dla pamięci sprzętowej i doskonałą precyzję operacji zmiennoprzecinkowych, tak miłą dla wszystkich tych terabajtów danych, przepływających przez różne rejestry "o podwójnej szerokości" 64-bitowego procesora. W przełożeniu na konkretne efekty 64 bity oznaczają większe bazy danych, krótszy czas transakcji i szybsze wykonywanie obliczeń.

Weterani produkcji sprzętu do utrzymywania baz danych, Sun Microsystems, IBM i Hewlett-Packard, zajmują się przetwarzaniem 64-bitowym od lat, dostarczając wysoko skalowalne platformy, obciążone wrodzoną wadą niezgodności z innymi systemami, o złożonych procedurach instalacyjnych i cenach zbliżonych do komputerów typu mainframe. Teraz u bram stanęli barbarzyńcy, próbując urwać dla siebie coś z wysokich marż zastrzeżonych dla systemów uniksowych. Spowszednienie technologii 64-bitowej zaczęło się wraz z systemami linuksowymi, opartymi na procesorach AMD Opteron i Intel Itanium. Pod koniec kwietnia tego roku Microsoft rzucił rękawicę, wprowadzając na rynek Windows Server 2003 Enterprise Edition i SQL Server 2000 Enterprise Edition dla 64-bitowych systemów Itanium.

Czy nadchodzi era 64-bitowego Wintela? Aby to sprawdzić, porównaliśmy wydajność 64-bitowych Windows Server 2003 i SQL Server 2000 z 32-bitowymi wersjami tych samych systemów, korzystając z podobnie skonfigurowanych, dwuprocesorowych serwerów IBM z procesorami Itanium 2 i Xeon - odpowiednio IBM eServer x450 i IBM eServer x335. Zbadaliśmy nie tylko czystą wydajność transakcyjną w dwu- i trzy warstwowych modelach klient-serwer, gdzie wyniki były bardzo obiecujące, ale wykonaliśmy również testy pod kątem wielu podstawowych komponentów, próbując ustalić, w jakim stopniu Microsoftowi udało się zoptymalizować kod Windows i serwera SQL do pracy 64-bitowej. Okazało się, że Redmond czeka jeszcze wiele pracy.

Ale to nie wszystko, bo 64-bitowe wersje Windows i SQL pozbawione są wielu funkcji, w które wyposażono 32-bitowe odpowiedniki, co ogranicza ich przydatność i utrudnia zarządzanie (zob. "64 bity ciągle w budowie" w tym numerze PCWK). Zwłaszcza brak 64-bitowej wersji .Net Framework sprawia, że nowa platforma jest praktycznie nieprzydatna do jakichkolwiek zastosowań poza dużymi bazami danych, rezydującymi w pamięci, oraz superdokładnymi operacjami zmiennoprzecinkowymi.

64-bitowy Windows uzyskał znacznie słabszy wynik od wersji 32-bitowej, wykonując różne rodzaje zadań DTS (Data Transformation Services), wykorzystywanych do manipulacji dużymi zestawami danych i zarządzania przepływami SQL.

64-bitowy Windows uzyskał znacznie słabszy wynik od wersji 32-bitowej, wykonując różne rodzaje zadań DTS (Data Transformation Services), wykorzystywanych do manipulacji dużymi zestawami danych i zarządzania przepływami SQL.

Do czasu, gdy Microsoft udostępni 64-bitową wersję .Net (beta jest oczekiwana na wiosnę 2004), Windows do Itanium nie będzie realną platformą aplikacji czy usług internetowych. Kolejna chmura, która zaciemnia wizję przyszłości, to niedojrzałość 64-bitowej architektury IA-64 Intela, którą wykazała platforma Intel Itanium, a obecnie Itanium w wersji dwuprocesorowej. Możliwości IA-64 ogranicza niska częstotliwość zegara (graniczna to ciągle zaledwie 1,5 GHz) i stosunkowo złożony model programistyczny, który wymaga poddania natywnego kodu IA-64 kilkustopniowemu testowaniu i dostrajaniu po kompilacji. Biorąc pod uwagę niedostatek aplikacji natywnych oraz nieprzyjazny model programistyczny, który każe podawać w wątpliwość jakość dostępnych aplikacji natywnych, większość działów informatycznych przedsiębiorstw powinna wybrać wobec Windows z Itanium postawę "poczekamy, zobaczymy".

Potoki i protokoły

Doświadczenie uczy nas, że prawdziwe przeszkody rzadko pojawiają się tam, gdzie ich oczekujesz. Przeciwnie, mają tendencję do podstawiania ci nogi wtedy, gdy robisz rzeczy mniej spektakularne, jak zarządzanie przepływem danych czy pisanie procedur automatyzacji procesów. Tak więc, oprócz skoncentrowania się na olbrzymim potencjale skalowalności, jaki zapewnia duża przepustowość pamięci oraz wieloterabajtowa przestrzeń adresowa architektury IA-64, zwróciliśmy uwagę na spoiwo programowe, które skleja różne kawałki nowej platformy.

Niektóre z tych komponentów są podstawowymi częściami składowymi systemu operacyjnego Windows. To IIS i wykonawczy ASP. Inne są integralną częścią poszczególnych aplikacji, takich jak SQL Server i DTS (Data Transformation Services). Jeszcze inne wykraczają poza granice systemu operacyjnego i aplikacji, zapewniając rodzaj powszechnych, krytycznych dla wydajności usług, które mogą utrzymać lub położyć całą platformę.

Dobry przykład, będący w dodatku zawsze bolesnym wrzodem dla programistów Windows, to pakiet MDAC (Microsoft Data Access Components). Ten zestaw protokołów i sterowników tworzy najważniejszy front-end wszystkich aplikacji dwuwarstwowych klient-serwer.

To element o fundamentalnym znaczeniu, umożliwiający interakcje transakcyjne w Windows, lingua franca wszystkiego, co wiąże się z bazami danych. Nieprawidłowość, która się tu pojawi - w wyniku złej optymalizacji lub prostego błędu programistycznego - może znacząco zmniejszyć wydajność dotkniętej nią aplikacji.

W 64-bitowym systemie operacyjnym brak jest wielu funkcji, które są standardowo w wersji 32-bitowej. Niektóre z nich mają krytyczne znaczenie dla funkcjonowania systemu.

W 64-bitowym systemie operacyjnym brak jest wielu funkcji, które są standardowo w wersji 32-bitowej. Niektóre z nich mają krytyczne znaczenie dla funkcjonowania systemu.

Byliśmy mile zaskoczeni, stwierdzając, że 64-bitowy pakiet MDAC w Windows Server 2003 do Itanium nie tylko dorównuje wersji 32-bitowej (testowanej w systemie Windows Server 2003 pracującej z dwuprocesorowym serwerem Xeon 3,06 GHz), ale wręcz przewyższa ją pod wieloma względami.

Na przykład Windows Server 2003 w teście dwuwarstwowych transakcji klient-serwer z SQL 2000 pracował z Itanium przeciętnie o 5 procent szybciej niż z Xeonem, przy takim samym obciążeniu ADO (ActiveX Data Objects). Wybór dostawcy danych nie miał przy tym żadnego znaczenia (OLE DB lub ODBC po TCP/IP i Named Pipes), a przecież wyniki zweryfikowaliśmy za pomocą ponad 30 wariacji obciążeń, protokołów i mechanizmów przesyłowych. Biorąc pod uwagę, jak wielki wpływ ma to spoiwo na ogólny poziom wydajności, trzeba stwierdzić, że Microsoft naprawdę się przygotował, optymalizując MDAC do architektury 64-bitowej. Rażące dysproporcje wydajności w tym obszarze byłyby wystarczającym powodem opóźnienia wszelkich planowanych wdrożeń klient-serwer.


Zobacz również