LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> 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 3023×

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

pridej.cz

 

DISKUZE

Nejsou žádné diskuzní příspěvky u dané položky.



Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

24.8.2016 6:44 /Ondřej Čečák
Poslední týden CFP LinuxDays 2016; pokud byste rádi přednášeli na LinuxDays 2016 8. a 9. října v Praze, můžete svůj příspěvek přihlásit, následovat bude veřejné hlasování.
Přidat komentář

9.8.2016 22:56 /Petr Ježek
Zařazení souborového systému reiser4 do jádra 4.7 znamená konečně konec patchování jádra jen kvůli možnosti použít reiser4.
Přidat komentář

12.7.2016 13:14 /František Kučera
Spolek OpenAlt zve na 130. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 21. července od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

11.7.2016 16:53 /Redakce Linuxsoft.cz
Konference LinuxDays hledá přednášející. Přihlášky poběží do konce prázdnin, v září bude hlasování a program. Více na https://www.linuxdays.cz/2016/cfp/.
Přidat komentář

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

21.4.2016 8:01 /František Kučera
Spolek OpenAlt zve na 127. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 28. dubna od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

12.8.2016 11:51 / Josef Zapletal
Jak udělat HTML/Javascript swiping gallery do mobilu?

8.8.2016 14:58 / Adams
fairies for hire

28.7.2016 15:51 / pepan
Re: NetBeans vs Eclipse

10.6.2016 21:10 / pavel riha
FreeBSD 10.3 a virtualizace

8.6.2016 21:56 / Milan Gallas
Nevalidní prefix m

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2016) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze