Kłopoty z benchmarkami

Tradycyjne metody pomiaru wydajności systemu zarządzania bazami danych nie nadają się do środowiska klient/serwer.

Tradycyjne metody pomiaru wydajności systemu zarządzania bazami danych nie nadają się do środowiska klient/serwer.

W informatycznym świecie istnieje takie powiedzonko: "kłamstwa, wierutne kłamstwa i benchmarki". Wskazują one wyraźnie, że mimo że każdemu użytkownikowi pomiar wydajności systemu komputerowego jest jakoś potrzebny, to nikt nie lubi benchmarków, uważając, że wprowadzają one zbyt duży margines błędu.

Opracowane kiedyś metody pomiaru wydajności, np. TPC-A i TPC-B, autorstwa Transaction Processing Council lub miara wydajności procesora SPECfp i SPECint są często bezużyteczne i nie są w stanie poradzić sobie z sytuacjami spotykanymi w codziennym życiu.

Z drugiej strony użytkownicy ciągle potrzebują jakiejś miary, pozwalającej upewnić się, że kupowany sprzęt i oprogramowanie spełni ich oczekiwania. Staje się to szczególnie palące przy przejściu z dużego komputera do środowiska przetwarzania rozproszonego.

Opracowanie benchmarków specjalnie dla potrzeb jednego użytkownika jest kosztowne i pracochłonne. Standardowe benchmarki jednak nie wystarczają, gdyż na ogół nie odpowiadają środowisku pracy użytkownika.

Co gorsza, w prasie fachowej często przytacza się opinie użytkowników wskazujące na to, że producenci oszukują przez tworzenie specjalnych konfiguracji sprzętowych, przeznaczonych do uzyskania dobrego wyniku testu, bądź przez takie dopasowanie programu, aby uzyskać najlepszą wydajność.

Obecnie już nikt nie wierzy w bezwzględne wartości podawane w benchmarkach. Posługują się nimi jedynie producenci sprzętu, pokazując w reklamach jak doskonałe wyniki on osiąga.

Jakie są inne metody oceny wydajności? Najprostsza polega na zapoznaniu się z podobną konfiguracją sprzętowo-programową w innej firmie i sprawdzeniu jak radzi sobie z codziennymi potrzebami. Inna polega na napisaniu specjalnych benchmarków dostosowanych do potrzeb lokalnych.

Niektóre firmy, pracujące w środowisku systemów otwartych opracowały dla własnych potrzeb pilotażową aplikację ściśle zgodną ze specyfikacją Unixa oraz SQL i zleciły jej uruchomienie na kilku wybranych systemach, oferowanych przez dostawców. Zajmuje im to na ogół nie więcej niż dwa, trzy dni. Taki test pozwala na porównanie wydajności w warunkach produkcyjnych.

Jednakże czasem wydajność nie jest tak ważna, jak to się sądzi. Każdy system, który przekroczył pewien próg wydajności (mierzony np. za pomocą TCP-A), nadaje się do proponowanego zastosowania. I wtedy zaczynają odgrywać rolę czynniki drugoplanowe, takie jak np. dostępność narzędzi do opracowania aplikacji, narzędzi do administrowania bazą czy możliwości jej strojenia już po wykonaniu aplikacji.


TOP 200