ARCHIV

Z historie transakčních testů

Podíváme se do historie TPC testů na dva dnes už zapomenuté rivaly - testy TPC-A a TPC-B.

20.9.2010 00:00 | Radim Kolář | Články autora | přečteno 5633×

Historie TPC testů

Odjakživa nastala potřeba testovat výkon aplikací. Zpočátku se výkon testoval subjektivně, což je nejpoužívanější metoda pro testování výkonu dodnes. Povětšinou totiž nepotřebujeme přesná čísla, ale to aby byla aplikace dostatečně rychlá pro naše potřeby. Spustíme proto aplikaci, přihlásíme uživatele, necháme je pracovat a pak se jich zeptáme zda byli s rychlostí spokojení. Tato testovací metodika ale neřeší problém s narůstajícím objemem dat. To co bylo rychlé před půl rokem nemusí být rychlé dnes, protože objem zpracovávaných dat vzrostl. Proto je potřeba syntetické testování.

Výkonnostní testy však nejsou jen aplikační. Když si budeme chtít porovnat systémy od různých výrobců budeme potřebovat nezávislý a dostatečně přesně definovaný test, který bude dostatečně přesně odrážet naše aplikační potřeby. Databáze se tradičně používají především pro transakční zpracování dat. Prvním testem transakčních systémů simulujícím provoz transakce z bankomatů byl TP1, který vyvinuli u IBM a dali ho jako public domain. Podmínky pro TP1 nebyly moc přesně specifikované a tak jej různí dodavatelé pojali různě, přirozeně tak aby dosáhli co nejlepšího score. Tato všeobecná vychytralost nepřidala rozhodně publikovaným výsledkům na věrohodnosti a proto bylo jasné že se dříve či později objeví lepší srovnávací test.

Nástupcem TP1 a předchůdcem TPC testů byl DebitCredit test (publikován 1985), který přinesl několik novinek.

1. Současně s výsledkem byla publikována cena systému

2. Implementační detaily testu byly nechány na dodavateli. Zadáno bylo co se má udělat, nikoliv jak se to má udělat.

3. Byly definovány scaleup pravidla. Systém s hodnocením 10 musí oproti systému s hodnocením 1 nejen zpracovat desetkrát více transakcí za sekundu, ale také zpracovat 10 krát více dat.

4. Byl zohledněn čas zpracování transakce. Bylo definováno jaké procento transakcí se musí stihnout v jakém časovém limitu.

5. Bylo definováno maximální povolené procentuální množství transakcí které mohou během testu selhat

6. Byla definována minimální a maximální doba testu

Zrození TPC

Myšlenka o nezávislém transakčním testu databází jednotlivých výrobců byla natolik zajímavá, že bylo v roce 1988 založeno konsorcium Transaction Processing Performance Council, které mělo za úkol přesně definovat podmínky testu a dohlížet na to aby jednotliví dodavatelé při testech nepodváděli. Každý výsledek testu hlášen TPC musel být doprovázen podrobným popisem jak bylo tohoto výsledku dosaženo a tento popis byl veřejnosti k dispozici. Toto byl jeden z hlavních úspěchů TPC. Doposud totiž výrobci svá nastavení testovacích systémů tajili a zákazníci si nemohli zakoupený systém přezkoušet, protože nevěděli jako ho pro test vyladit a kupovali tedy prakticky zajíce v pytli.

TPC-A

První test který z dílen TPC konsorcia po roce práce vyšel byl TPC-A. Vycházel z testu DebitCredit a bylo dbáno na to aby byl test dostatečně realistický a odpovídal dostatečně přesně běžnému zpracovávání transakcí v dosavadní bankovní praxi. Tento test se stal velmi populárním a noví členové TPC konsorcia přibývali jak houby po dešti. V roce 1994 když vyšla verze 2.0 testu TPC-A bylo v TPC zastoupeno téměř 50 společností. V té době ještě nebyl trh rozdělen mezi malý počet velkých hráčů. Firem zabývajících se transakčním zpracováním bylo hodně - byl zde prostor pro inovaci a vzájemnou soutěživost. Přirovnat by se to dalo k éře 8-mi bitových počítačů, kde bylo hodně konkurenčních produktů. S přechodem na platformu IBM PC se počítač stal komoditou a prakticky jediné inovace vycházeli z dílen IBM a později Intelu, když se uvolňovali specifikace nových součástí.

V testu TPC-A se jedná o simulaci transakcí zadávaných pomocí terminálů připojených k centrálnímu systému přes LAN, případně WAN. Test byl velmi realistický - simuloval běžný bankovní provoz. Nejednalo se o pouhý test databáze, ale o test celého systému včetně terminálů a síťových zařízení, které se také počítaly do celkové ceny systému. Byl to takzvaný end-to-end benchmark. Tento druh testu vyhovoval systémovým integrátorům, kteří si tak mohli velmi dobře mezi sebou porovnávat cenu a výkon svých řešení.

TPC-B

Tato end-to-end testovací metodika nevyhovovala dodavatelům serverů a databází. Chtěli si také vzájemně porovnávat prodávané systémy, ale TPC-A se jim zdál příliš komplexní protože dodávali jen server, nikoliv celé řešení. Proto byl vytvořen a v roce 1990 vydán druhý test s názvem TPC-B. TPC-B byl podmnožinou dosavadního TPC-A. To byla jeho hlavní výhoda. Nebylo potřeba získávat nové know how jak vyladit databázový systém pro tento test, protože se jednalo o starý známý test jen bez připojených terminálů. Popularita TPC-B byla větší než TPC-A a tak můžeme říci, že ho po dvou letech zcela nahradil.

TPC-A vs TPC-B

Jak můžeme tušit, tak mezi zastánci testů docházelo ke sporům, který test je lepší a proč. Zastánci TPC-B kteří reprezentovali prodejce serverů a databází tvrdili že TPC-B lépe vystihuje potřeby segmentu kterému prodávají, zatímco zastánci TPC-A argumentovali že vynecháním terminálů a síťových komponent dochází k nerealisticky vysokým počtům transakcí za sekundu a ceně za transakci. Nakonec vyhrál TPC-B protože pomohl lépe realizovat cíl podnikání - aneb maximalizaci zisku. TPC-B výsledky byly lepší, ceny za transakci menší a tudíž se systémy které měli TPC-B prodávali výrazně lépe než systémy ohodnocené TPC-A.

Oba dva testy se sice nějaký čas používali současně, ale TPC-B rychle převládl, protože zákazníci porovnávali výsledky TPC-B oproti TPC-A i když se jednalo o různé testy a tak se žádný prodejce nechtěl znevýhodnit, protože ty tps čísla byly v TPC-B větší a cena menší. Toto opět dokázalo, že v našem světě platí nepřímá úměrnost mezi rozhodovacími pravomocemi a znalostmi.

Velký důraz se kladl na zachování důvěryhodnosti TPC testu. Firmy do něj již investovaly nemalé prostředky a bylo potřeba dbát aby tento test odborná veřejnost brala vážně. Proto se dbalo jak na literu testu, tak na jeho ducha. Kupříkladu firma Oracle přišla s disktrétními transakcemi, které byly optimalizovány pro TPC-A. Při použití těchto transakcí aplikace nevidí sebou provedené změny a negeneruje se rollback zaznam pro transakci, protože změny provedené transakcí jsou uložené v paměti a teprve po provedení COMMIT se zapíší do databáze. Tento hack bych čekal spíš u MySQL než u Oracle. TPC rozhodlo, že tento typ transakcí by zákazník při reálném nasazení nepoužil a proto jej zakázala a Oracle stáhlo všechny TPC výsledky kde byly použity.

TPC-C

TPC-A a TPC-B testům byla vytýkána jejich jednoduchost. Nereprezentovali dost dobře komplexní transakční úlohy. Databázové schema bylo navíc velmi jednoduché, což byla na jednu stranu i výhoda - snadněji se implementovalo. Transakce v TPC-A/B vždy měnily obsah databáze, což nastává v praxi jen zřídka, pokud nepočítáme batch úlohy. Povětšinou tvoří zápisové operace u OLTP systémů okolo 20%. Bylo jasné, že je potřeba přijít s novým testem a tak se zrodil v roce 1992 test TPC-C. Tento test byl horká novinka, jeho implementace zabrala společnostem nějaký čas a trvalo mu několik let než vytlačil a zcela nahradil TPC-B. TPC-C se používá jako primární test pro OLTP úlohy dodnes a to i přestože byly vytvořené novější podobné testy.

TPC-E

TPC-E měl být nástupcem TPC-C. Databázové schema se rozrostlo, referenční integrita (foreign keys check) byla oproti TPC-C vyžadována a test obsahoval více datových typů - přibyl typ boolean a LOB. Tento test se neujal mimo platformu MS-Windows/MS SQL. Velké databáze jako je Oracle a DB2 nemají zájem soutěžit v tomto testu, protože není tak prestižní jako TPC-C. Firma IBM se TPC-E zúčastňuje, ale pouze na platformě MS Windows s Microsoft SQL Serverem jak vidíme ve výsledcích.

Příště

Příště si popíšeme podrobněji TPC-B test a otestujeme v něm několik nejběžnějších databází. Článek o TPC-C nechystám, protože podmínky pro standardní TPC-C test se těžko realizují ve volném čase na domácím HW. To je hlavní důvod proč nevidíme blogy na téma Jak jsem včera testoval TPC-C v MySQL. Ono i to TPC-B moc doma neotestujete pokud chcete dosáhnout rozumného výkonu a dodržet daná pravidla, ostatně uvidíte v dalším dílu sami.

Verze pro tisk