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

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ů

20.5.2018 17:45 /Redakce Linuxsoft.cz
Ve čtvrtek 31. května 2018 připravuje webový magazín BusinessIT ve spolupráci s Best Online Média s.r.o. pátý ročník odborné konference Firemní informační systémy 2018. Akce proběhne v kongresovém centru Vavruška (palác Charitas), Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 15 hod. odpoledne. Konference je zaměřena na efektivní využití firemních informačních systémů a na to, jak plně využít jejich potenciál. Podrobnější informace na webových stránkách konfrence.
Přidat komentář

14.5.2018 7:28 /František Kučera
Květnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 17. 5. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: Audio – zvuk v GNU/Linuxu.
Přidat komentář

7.5.2018 16:20 /František Kučera
Na stránkách spolku OpenAlt vyšla fotoreportáž Pražské srazy 2017 dokumentující srazy za uplynulý rok. Květnový pražský sraz na téma audio se bude konat 17. 5. 2018 (místo a čas ještě upřesníme).
Přidat komentář

17.4.2018 0:46 /František Kučera
Dubnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 4. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tématem tohoto srazu bude OpenStreetMap (OSM) aneb svobodné mapy.
Přidat komentář

16.3.2018 22:01 /František Kučera
Kulatý OpenAlt sraz v Praze oslavíme klasicky: u limonády a piva! Přijďte si posedět, dát si dobré jídlo a vybrat z mnoha piv do restaurace Kulový blesk, který najdete v centru Prahy nedaleko metra I. P. Pavlova na adrese Sokolská 13, Praha 2. Sraz se koná ve čtvrtek 22. března a začínáme v 18:00. Heslo: OpenAlt. Vezměte s sebou svoje hračky! Uvítáme, když si s sebou na sraz vezmete svoje oblíbené hračky. Jestli máte nějaký drobný projekt postavený na Arduinu, nějakou zajímavou elektronickou součástku, či třeba i pěkný úlovek z crowdfundingové akce, neváhejte. Oslníte ostatní a o zábavu bude postaráno.
Přidat komentář

13.2.2018 0:41 /František Kučera
Únorový pražský sraz OpenAltu se koná 15. 2. 2018 a tentokrát se vydáme na návštěvu do jednoho pražského datacentra. Sejdeme se v 17:50 v severovýchodní části nástupiště tramvajové zastávky Koh-I-Noor. Po exkurzi se přesuneme do restaurace U Pštrosa (Moskevská 49), kde probereme tradiční témata (svobodný software a hardware, DIY, CNC, SDR, 3D tisk…) a tentokrát bude k vidění i IoT brána od The Things Network.
Přidat komentář

11.2.2018 23:11 /Petr Ježek
Hledáte lehký a rychlý prolížeč PDF souborů? Pokud vás již omrzelo čekat na načítání stránek či jiné nešvary, zkuste xreader.
Přidat komentář

11.2.2018 20:35 /Redakce Linuxsoft.cz
Třetí ročník odborné IT konference na téma Cloud computing v praxi proběhne ve čtvrtek 1. března 2018 v konferenčním centru Vavruška, v paláci Charitas, Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 16 hod. odpoledne. Konference o trendech v oblasti cloud computingu nabídne i informace o konkrétních možnostech využívání cloudů a řešení vybraných otázek souvisejících s provozem IT infrastruktury.
Přidat komentář

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

> Poslední diskuze

20.2.2018 18:48 / Ivan Majer
portal

20.2.2018 15:57 / Jan Havel
Jak využíváte služby cloudu v podnikání?

16.1.2018 1:08 / Ivan Pittner
verejna ip od o2 ubuntu

15.1.2018 17:26 / Mira Harvalik
Re: Jak udělat HTML/Javascript swiping gallery do mobilu?

30.12.2017 20:16 / Michal Knoll
odmocnina

Více ...

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