TPC – modelowanie rzeczywistości: część 2

Bohdan Szymczak

Opisany w pierwszej części artykułu test standardu TPC-A był pierwszą próbą wykonania modelu systemu informatycznego obsługującego rzeczywisty bank. Umożliwiał określenie wydajności, mierzonej jako liczba transakcji na sekundę (tps), co dawało możliwość obiektywnego porównania różnych środowisk sprzętowych i systemowych.

Należy jednak podkreślić, że zastosowane uproszczenia, w szczególności maksymalnie zredukowana liczba tabel bazodanowych oraz symulacja jedynie elementarnej operacji biznesowej – wpłaty/wypłaty kasowej, nie dawały możliwości przeniesienia uzyskanych wartości z testu na rzeczywiste systemy bankowe.

W kolejnych latach opracowano bardziej złożone testy, które w większym stopniu modelowały rzeczywistość. Zanim jednak do tego doszło, wykorzystano model bazodanowy, pochodzący ze standardu TPC-A, do opracowania nowego testu.

Nadchodzi Wersja B

Test, sygnowany oznaczeniem TPC-B, był zorientowany na osiągnięcie maksymalnie możliwego obciążenia systemu bazodanowego. W tym celu wyeliminowano wszystkie składniki infrastruktury, które mogły spowolnić działanie bazy. W teście nie używa się terminali symulujących pracę operatorów, możliwe jest również całkowite wyeliminowanie komunikacji sieciowej pomiędzy aplikacją obciążającą bazę a serwerem bazy. Dopuszcza się użycie aplikacji rezydującej bezpośrednio na serwerze bazy danych. Kolejnym czynnikiem różniącym test TPC-B od TPC-A jest wyeliminowanie czasu bezczynności pomiędzy kolejnymi transakcjami, który był niezbędny do symulacji czasu aktywności operatora, niezwiązanej z bezpośrednią obsługą aplikacji. W efekcie uzyskuje się test, w którym kolejne transakcje są realizowane bez przerwy, co skutkuje bardzo silnym obciążeniem systemu.

Poza modelem bazodanowym pochodzącym z testu TPC-A, użyto analogicznego profilu transakcji biznesowej, zatem jedyną istotną różnicą w obydwu testach był sposób obciążenia maszyny bazodanowej. Standard dopuszcza kilka wariantów budowy środowiska testowego; dla ilustracji zasadniczych różnic zamieszczono w niniejszym opracowaniu dwa przykłady.

Rysunek nr 1 pokazuje klasyczny wariant środowiska testowego standardu TPC-A w architekturze klient/serwer, z użyciem zdalnych emulatorów terminali (RTE – Remote Terminal Emulator).


Rys. 1.
Przykładowa architektura dla testu TPC-A.

Rysunek nr 2 pokazuje wariant środowiska testowego standardu TPC-B, w którym obciążenie jest generowane przy użyciu aplikacji osadzonej na serwerze bazy danych.


Rys. 2.
Przykładowa architektura dla testu TPC-B.

Różnice w sposobie przeprowadzenia testów obydwu standardów są na tyle duże, że osiągnięte rezultaty, pomimo stosowania jednakowej miary – tps, nie mogą być ze sobą porównywane. Wykonując jednak dla tego samego środowiska obydwa testy, można z uzyskanych wartości wydajności wnioskować o przewidywanym zachowaniu się systemu w warunkach obciążenia o różnej charakterystyce.

Jak działa TPC-B?

Opracowany test TPC-B, którego głównym celem było uzyskanie maksymalnego obciążenia systemu bazodanowego, symulował działanie rzeczywistego systemu bankowego w trakcie przetwarzania wsadowego. Tego typu funkcjonalność jest w rzeczywistych systemach bankowych realizowana jako tzw. operacje masowe, związane najczęściej z zamknięciem dnia operacyjnego, lub wykonywaniem innych operacji automatycznych na zbiorze danych. Przykładem takich operacji może być: księgowanie rozliczeń międzybankowych, naliczanie odsetek na koniec okresu, pobieranie prowizji za prowadzenie rachunku itp.

Test standardu TPC-B umożliwiał przede wszystkim silne obciążenie podsystemu dyskowego, sprawdzając zdolność systemu do zapisu dużej ilości zmian do bazy danych, w tym również rejestracji zatwierdzanych transakcji. Porównując go do rzeczywistego działania systemu bankowego, widać jego dużą słabość. O ile w przypadku testu TPC-A można znaleźć analogię do bardzo uproszczonej operacji wpłaty gotówkowej, o tyle w przypadku testu TPC-B, ograniczenie liczby tabel uczestniczących w transakcji biznesowej staje się kluczowym ograniczeniem. Dodatkowo zaznacza się brak dużych operacji odczytu z bazy danych.

Operacje masowe w rzeczywistych systemach bankowych charakteryzują się na ogół dużym udziałem operacji odczytu, co wynika chociażby z konieczności wyboru zbioru spełniającego kryteria przetwarzania z puli wszystkich rachunków. Dodatkowo, udział szeregu innych tabel powoduje, że na wynik wydajnościowy składa się więcej czynników, niż tylko proste operacje zapisu księgowego na rachunku.

Kolejny test: TPC-C

Jak wspomniano w pierwszej części artykułu, stopień komplikacji współczesnych systemów bankowych jest nieporównywalny do standardów pierwszych testów opracowanych przez Transaction Processing Performance Council. Dotyczy to nawet w większym stopniu operacji masowych niż detalicznych, gdyż obecnie główny wolumen skomplikowanego przetwarzania odbywa się właśnie w trakcie przetwarzania masowego. Najbardziej skomplikowane algorytmy, takie jak obliczanie efektywnej stopy procentowej, czy też utraty wartości księgowej są realizowane właśnie w tych operacjach. Jest faktem, że współczesne systemy bankowe, choć ewolucyjnie wywodzą się w większości z systemów księgowych, stanowią bardzo złożony mechanizm, w którym księgowość stanowi tylko jeden z elementów.

Trzeba jednak uczciwie przyznać, że w chwili opracowywania obydwu testów: TPC-A i TPC-B, pochodzących z początku lat dziewięćdziesiątych ubiegłego wieku, tak skomplikowane przetwarzanie nie było dostępne w informatycznych systemach bankowych, ani też nie występowało w księgowości bankowej. Należy również podkreślić, że pierwsze standardy testów wydajnościowych umożliwiły zebranie doświadczeń w tym obszarze i stanowiły punkt wyjścia dla opracowania kolejnych, które w większym stopniu zbliżały się do rzeczywistości.

Wiodącym testem dla systemów typu OLTP stał się opracowany w 1992 roku standard TPC-C. W odróżnieniu od opisanych wcześniej, symulował on system sprzedaży w wielooddziałowej sieci magazynów (hurtowni) i obejmował pięć operacji typowych dla działalności handlowej, takich jak: złożenie nowego zamówienia, płatność, sprawdzenie statusu złożonego zamówienia, realizacja dostawy i kontrola poziomu zapasów magazynowych.

Implementacja bazodanowa obejmuje 9 tabel. Przed wykonaniem testu baza jest inicjalnie wypełniana wierszami. Wielkość alokacji przestrzeni bazy danych musi odpowiadać 60-dniowej pracy systemu przy założeniu ciągłej 8-godzinnej pracy dziennej. Model biznesowy implementuje grupę magazynów obsługujących 10 okręgów sprzedaży każdy. Z kolei każdy okręg obsługuje 3 000 klientów, zaś wszystkie magazyny posiadają na składzie 100 000 pozycji towarowych na sprzedaż.

Symulacja działania systemu jest bardzo zbliżona do opracowanej w teście TPC-A, to znaczy emulowane są terminale klienckie, wraz z określonymi czasami opóźnień między operacjami, które mają naśladować czynności wykonywane przez rzeczywistego operatora. Można zatem stwierdzić, że standard TPC-C jest rozwinięciem i udoskonaleniem testu TPC-A, zaś komplikacja struktur bazodanowych oraz zwiększenie szczegółowości emulowanych operacji biznesowych, w zdecydowanie większym stopniu zbliża ten standard do systemów rzeczywistych.

Istotną różnicą w stosunku do TPC-A jest jednoczesne symulowanie grupy pięciu różnych transakcji biznesowych. O ile w teście TPC-A wykonywano tylko jedną operację kasową – wpłatę lub wypłatę gotówkową, to w teście TPC-C zasymulowano działalność handlową zbliżoną do rzeczywistej.

W warunkach rzeczywistych głównymi operacjami w systemie jest przyjmowanie zamówień i realizacja płatności, zaś operacje pozostałe stanowią stosunkowo niewielki udział. W teście określono, że wiodąca operacja, którą stanowi składanie zamówienia obejmuje 45% wszystkich transakcji, realizacja płatności – 43%, zaś pozostałe operacje jedynie 12%.

Wynikiem działania tak zdefiniowanego modelu jest dosyć złożony obraz przetwarzania bazodanowego, który uwzględnia wszystkie podstawowe operacje na danych, tzn. select, insert, update i delete, wykonywane równocześnie w trakcie trwania testu. Zróżnicowany jest również charakter poszczególnych typów transakcji biznesowych. Miarą wydajności jest liczba transakcji biznesowych na minutę, oznaczana tako tpmC.

Sukces wersji C

Szczegółowy opis standardu TPC-C został umieszczony w 33 numerze PLOUG-tek [6], zaś próba odniesienia wyników tego testu na systemy bankowe została opisana w [7].

Standard TPC-C okazał się na tyle dobry, iż jest stosowany do dnia dzisiejszego, modyfikowany i udoskonalany wraz z rozwojem sprzętu. Obecna wersja nosi numer 5.10.1 i w stosunku do wersji wcześniejszych zawiera głównie zmiany dotyczące obliczeń kosztu finansowego pojedynczej transakcji, wymagań dotyczących wielkości bazy danych oraz czasu trwania testu.

Sukces standardu jest niewątpliwie zasługą dobrze zdefiniowanego modelu testowego, symulującego rzeczywistą działalność sieci handlowej, przy zastosowaniu stosunkowo prostego składu danych i nieskomplikowanej definicji transakcji biznesowych. Należy podkreślić, że jakkolwiek rzeczywiste systemy informatyczne składają się z setek, a nawet tysięcy tabel w bazie danych, to główne źródło obciążenia koncentruje się zwykle na niewielkim podzbiorze kluczowych tabel, składających się na jądro systemu. Ta cecha umożliwia dla potrzeb wydajnościowych symulację złożonych systemów przy pomocy względnie prostych modeli i uzyskiwanie dobrych przybliżeń.

Przeprowadzane przez TPC testy dały możliwość oceny dostępnych na rynku serwerów, macierzy oraz systemów baz danych pod kątem ich wydajności. Niezależnie od tego, dodatkową wartością stała się możliwość skonfrontowania wyników testów standardu TPC-C z wynikami podobnie skonstruowanych testów dla rzeczywistych systemów informatycznych.

Korzystając z dostępnych na rynku automatów testowych, lub własnego oprogramowania, można wykonać analogiczny test dla rzeczywistych aplikacji obsługujących działalność handlową.

Uzyskany wynik może być miarą doskonałości systemu. Jakkolwiek trudno oczekiwać, żeby system rzeczywisty był zdolny osiągnąć wyniki modelu, to stopień zbliżenia się do niego może wskazywać na jakość aplikacji. Może być również przesłanką odnośnie potencjalnych możliwości tuningowych oraz określenia wielkości obszaru teoretycznych rezerw wydajnościowych.

Wielką zaletą modelu TPC-C jest jego funkcjonowanie, w niewiele zmieniającej się postaci, od chwili opracowania do dnia dzisiejszego. Dostępność opublikowanych wyników nie tylko ułatwia wybór i dostosowanie maszyny do potrzeb użytkownika, ale również umożliwia ciekawą analizę historyczną, na porównywalnych danych.

Obecnie dostępne jest ponad 250 wyników testów wykonanych zgodnie ze standardem TPC-C. Testom poddano szereg maszyn o różnej wydajności i najpopularniejsze bazy danych: Oracle, Microsoft SQL Server, DB2 a wcześniej również Sybase. Ambicją każdego producenta stało się oczywiście umieszczenie własnego serwera na szczycie wydajności.

Na potrzeby niniejszego opracowania i ilustracji zmian wyników w czasie, wybrano z publikowanych danych najlepsze rezultaty. Tabela nr 1 zawiera zestawienie najlepszych wyników osiągniętych przez pojedynczą, niesklastrowaną maszynę bazodanową w kolejnych latach. Do zestawienia wybrano najlepszy wynik osiągnięty w danym roku kalendarzowym, o ile był on lepszy niż w roku poprzedzającym.

Tabela 1. Zestawienie najlepszych wyników dla niesklastrowanych serwerów.

Rok Wydajność
[tpmC]
Koszt jednost.
[$/tpmC]
System CPU Baza Danych System operacyjny
1997 13 089,30 35,44 ALR Revolution 6X6 (1MB L2) (c/s) Intel PentiumPro – 200 MHz Microsoft SQL Server Enterprise Edition 6.5 Microsoft Windows NT Enterprise Edition 4.0
1998 18 666,73 116,66 Bull Escala RL470 (c/s) IBM PowerPC RS64 – 125 MHz Oracle Oracle8 Enterprise Edition 8.0 IBM AIX 4.3.0
1999 23 235,57 16,66 AcerAltos 21000 c/s IBM IBM RS64-III – 450 MHz Microsoft SQL Server Enterprise Edition 7.0 Microsoft Windows NT Enterprise Edition 4.0
2000 220 807,27 43,31 Bull Escala EPC2450 IBM RS64-IV – 600 MHz Oracle 8i Enterprise Edition IBM AIX 4.3.3
2001 389 434,40 16,41 HP Superdome – PA-RISC/750 MHz-64p/64c HP PA-RISC 8700 – 750 MHz Oracle 9i Database Enterprise Edition HP UX 11.i 64-bit
2002 423 414,41 15,64 HP Superdome – PA-RISC/875 MHz-64p/64c HP PA-RISC 8700 – 875 MHz Oracle 9i Enterprise Database Server 9.2.0.1 HP UX 11.i 64-bit
2003 1 008 144,49 8,33 HP Integrity Superdome – Itanium2/1.5 GHz-64p/64c Intel Itanium2 – 1.5 GHz Oracle Database 10g Enterprise Edition HP UX 11.iv2 64-Bit Base OS
2004 3 210 540,63 5,07 IBM eServer p5 595 IBM POWER5 – 1.9 GHz IBM DB2 UDB 8.2 IBM AIX 5L V5.3
2005 3 210 540,63 5,07 IBM eServer p5 595 IBM POWER5 – 1.9 GHz IBM DB2 UDB 8.2 IBM AIX 5L V5.3
2006 3 210 540,63 5,07 IBM eServer p5 595 IBM POWER5 – 1.9 GHz IBM DB2 UDB 8.2 IBM AIX 5L V5.3
2007 4 092 799,00 2,93 HP Integrity Superdome-Itanium2/1.6GHz/24MB iL3 Intel Itanium2 – 1.6 GHz Oracle Database 10g R2 EE w/Partitioning HP-UX 11i v3
2008 6 085 166,00 2,81 IBM Power 595 Server Model 9119-FHA IBM POWER6 – 5.0 GHz IBM DB2 9.5 IBM AIX 5L V5.3
2009 6 085 166,00 2,81 IBM Power 595 Server Model 9119-FHA IBM POWER6 – 5.0 GHz IBM DB2 9.5 IBM AIX 5L V5.3

Jak widać, w ciągu ostatnich dziesięciu lat nastąpił ogromny postęp w wydajności przetwarzania transakcyjnego – prawie trzystukrotny wzrost wydajności jest wynikiem zarówno postępu w budowie wysokowydajnych, wieloprocesorowych serwerów i macierzy, jak i rozwoju oprogramowania baz danych.

Rysunek nr 3 obrazuje rosnący trend wzrostu wydajności, co niewątpliwie jest efektem popytu na wysokowydajne systemy baz danych. Z drugiej strony widać, że kolejne rekordy trudno pobić w krótkim czasie – 3 miliony tpmC osiągnięte w 2004 roku okazały się rekordem nie do pobicia przez kolejne 3 lata, zaś obecny rekord – ponad 6 milionów tpmC został osiągnięty już rok temu.


Rys. 3.
Trend wzrostu wydajności.

Wzrostowi wydajności towarzyszy, choć w mniejszym stopniu, spadek kosztów. Obrazuje to Rysunek nr 4. Chociaż koszt uzyskania jednego tpmC spadł w ciągu ostatnich 10 lat około dziesięciokrotnie, to jednak wydaje się, że dalsza dynamika spadku będzie słabła. Być może jest to również skutek zmniejszenia się konkurencji na rynku producentów najsilniejszych serwerów baz danych. Z analizy wyników z ostatnich lat można wyciągnąć wniosek, że na rynku pozostało już tylko dwóch liczących się konkurentów: IBM i HP. To między nimi toczy się od kilku lat rywalizacja o prymat pierwszeństwa na liście wyników TPC-C.


Rys. 4.
Kształtowanie się kosztów transakcji.

Co dalej z testami TPC?

Jakkolwiek standard TPC-C jest ciągle w użyciu, to jego konstrukcja pochodząca z 1992 roku, coraz mniej przystaje do współczesnych, coraz bardziej złożonych i skomplikowanych systemów informatycznych. Ze względu na wspomnianą wcześniej zaletę, jaką jest duża baza wyników testów, a co za tym idzie możliwość porównywania osiągniętych wartości tpmC, ten standard pozostanie najprawdopodobniej w użyciu jeszcze przez następne lata.

Potrzeba opracowania nowocześniejszego systemu, modelującego w większym stopniu rzeczywiste systemy informatyczne zaowocowała opracowaniem nowego testu. W lutym 2007 roku opublikowano standard TPC-E, który tym razem modelował system obsługujący usługi maklerskie. Konstrukcja składu danych, oraz właściwy dobór transakcji spowodował jednak, że test ten może być uznany także za model reprezentatywny dla większości innych nowoczesnych, złożonych systemów OLTP.

Bibliografia:

  1. www.tpc.org
  2. TPC BENCHMARKTM A, Standard Specification, Revision 2.0, 7 June 1994
  3. TPC BENCHMARKTM B, Standard Specification, Revision 2.0, 7 June 1994
  4. TPC BENCHMARKTM C, Standard Specification, Revision 5.10.1, February 2009
  5. TPC BENCHMARKTM E, Standard Specification, Version 1.7.0, November 2008
  6. Bohdan Szymczak – Wydajność systemów bazodanowych Oracle. PLOUG’tki nr 33, marzec 2005.
  7. Bohdan Szymczak – Wydajność systemów bazodanowych Oracle. Część II, PLOUG’tki nr 34, czerwiec 2005.

TPC BenchmarkTM , TPC-A, TPC-B, TPC-C, tpmC, TPC-E, tpsE są zastrzeżonymi znakami handlowymi Transaction Processing Performance Council.

Opisy i rysunki zaczerpnięte z publikacji TPC zostały zamieszczone za zgodą Transaction Processing Performance Council (TPC).