ARCHIV

Implementace TPC-B testu

Podíváme se na tři programy co implementují TPC-B benchmark a všimneme si jak věrně následují TPC-B standard.

21.10.2010 11:00 | Radim Kolář | Články autora | přečteno 5748×

TPC-B specifikace

V minulém díle jsme si dopodrobna vysvětlili TPC-B test. Podrobnější popis TPC-B verze 2.0 najdete v officiální specifikaci standardu. Na jeho domovské stránce dnes najdete jen jeho stručný popis a odkaz na zmiňovaný dokument. Výsledky TPC-B byly již odstraněny, protože je dnes již TPC-B považován za zastaralý a plně nahrazen TPC-C. Je to docela škoda. Z historického hlediska by bylo velmi zajímavé si přečíst full disclosure dokumenty popisující konfiguraci systémů. V dokumentu který popisuje historii TPC testů a stal se tak předlohou pro předminulý článek najdeme jen první reportovaný výsledek 102.94 tpsB ($4,167 per tpsB) a nejlepší dosažený výsledek 2,025 tpsB ($254 per tpsB).

TPC-B implementace

Dnes se podíváme na programy, které jej implementují nebo které jsou mu alespoň dostatečně blízké. Pokud si nechcete TPC-B naprogramovat jako cvičení vašich programátorských dovedností tak se vám existující TPC-B implementace budou hodit. Tyto implementace povětšinou implementují pouze tzv. transaction profile. Implementace testů na korektnost vyžadovaných TPC-B často chybí. Implementace základního TPC-B testu je velmi jednoduchá; já osobně bych tento test probíral na hodinách programování a jeho naprogramování dal studentům za domácí úkol.

PGBench

pgbench je pravděpodobně nejznámější implementace TPC-B. Je to součást standardních utilit k databázi PostgreSQL a je často používán k porovnávání výkonu. Skutečnost, že tento test je vlastně variací na TPC-B není všeobecně příliš známa ačkoliv je to vypisováno během testu na obrazovku.

PGbench nesplňuje podmínky TPC-B v těchto bodech:

1. Není úmyslně dodržena minimální požadovaná délka řádků z důvodu zpětné kompatibility výsledků.

2. Delta u transakcí je od -5000 do 5000 místo 6ti číslic.

3. Stavy účtů jsou uloženy jako 4 bajtový integer místo 10ti platných číslic.

Když se podíváme do zdrojových textů pgbench.c na řádky 1227-1235 tak uvidíme že pgbench pravděpodobně TPC-B kompatibiliní nebude nikdy, což je docela škoda protože se jedná o šikovný testovací program.

Použití pgbench je jednoduché. Nejprve vytvoříme tabulky a naplníme je daty. Zadává se scale factor, který je počtem vytvořených poboček a jak víme z minula je maximální uznanou tpsB hodnotou, pokud by tedy byla dodržena TPC-B kompatibilita. Minimální hodnotu doporučuji nastavovat na 10 abychom se vyhnuli zbytečnému čekání na zámky.

> pgbench -i -s 10 postgres
creating tables...
10000 tuples done.
[..]
1000000 tuples done.
set primary key...
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will ...
vacuum...
done.

Testování je také jednoduché, zadáme počet simulovaných klientů a počet transakcí na klienta. Klientů doporučuji používat alespoň 4 či více a počet transakcí na klienta minimálně 10000.

> command time pgbench -c 4 -t 10000 postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 4
number of transactions per client: 10000
number of transactions actually processed: 40000/40000
tps = 269.411038 (including connections establishing)
tps = 269.435388 (excluding connections establishing)
      150.90 real         1.89 user         1.55 sys

JDBCBench

Další implementaci TPC-B jsem našel na stránkách výrobce pro mne doposud neznámé databáze Mimer SQL. Zdrojový kód programu v Javě je zde.

Kromě vlastního programu stojí za to zmínit i hezký článek o tom jak dosahovat slušného výkonu v JDBC aplikacích, kde jsou vyučované postupy demonstrovány v TPC-B testu na databázích MySQL (MyISAM i InnoDB) a Mimer SQL. Rad na toto téma není nikdy dost, protože ačkoliv jsou popisované postupy všeobecně známé tak je pořád většina JDBC aplikací dodnes nepoužívá z důvodů neznalosti jejich autorů. Rady si tady shrneme:

1. Uzavírejte databázové zdroje - nespoléhejte se na garbage collection v Javě. Podle grafu na jejich stránkách je zrychlení tímto dosažené prakticky neměřitelné, nicméně se tím snižuje zátěž databázového serveru a paměťová náročnost aplikace. Zejména dobré je včas zavírat spojení do databáze.

2. U opakovaných dotazů používejte PreparedStatement. SQL dotaz se nebude muset pokaždé parsovat a optimalizovat, což vede u krátce se vykonávajících dotazů k razantnímu nárůstu výkonu. Dosažená zrychlení oproti klasickému Statement bývají 2-4x v závislosti na použité databázi a SQL dotazu. Jako vedlejší efekt dostaneme takříkajíc v ceně i obranu proti závažnému bezpečnostnímu problému SQL Injection.

3. Používejte transakce - transakce nejen zajišťují tzv. ACID konzistenci dat, ale i zrychlují vykonávání programu protože se nemusí po každém SQL příkazu čekat až se data zapíší na disk. Databázi musíme přepnout ze standardního autocommit režimu pomocí Connection.setAutoCommit(false);.

4. Používejte uložené procedury. V TPC-B uložené procedury zvednou zhruba trojnásobně výkon, protože namísto poslání čtyř příkazů stačí databázi poslat jen jeden. Ušetří se tím doba a režie spojená s posíláním příkazů po síti. Uložené procedury jsou ale naneštěstí nepřenositelné mezi jednotlivými databázemi.

JDBCBench je poměrně dobře a přehledně napsán. Jednak je to dáno tím že jej programovali lidé s dobrou znalostí problematiky a přehlednosti přispěl také programovací jazyk Java v kterém se dobře programuje strukturovaně a objektově. Napsat v Javě nepřehledný program je tak mnohem těžší než v C nebo Perlu.

JDBCBench nesplňuje podmínky TPC-B v těchto bodech:

1. Delta u transakcí je 0 až 1000 místo 6ti číslic t.j. od -999999 do 999999

2. Stavy účtů jsou uloženy jako 4 bajtový integer místo 10ti platných číslic

Pokud potřebujete jednoduchý TPC-B v jazyce Java, tak si v JDBCBench upravte výše zmíněné chyby, což je záležitostí několika málo minut. Rozhodně je to výrazně jednodušší než opravovat PGBench.

JDBC TPC-B

Protože jsem potřeboval TPC-B test který by byl dostatečně modulární aby uměl testoval více databází a žádný takový jsem nenašel tak jsem jej byl nucen napsat. Jako programovací jazyk jsem zvolil Javu, protože realné aplikace budou s největší pravděpodobností v Javě napsány a zajímala mne také výkonnost jednotlivých JDBC driverů. Podporovány jsou databáze Oracle, DB2, Derby, MySQL, PostgreSQL a generic JDBC. U všech databází je využito maximálně jejich přirozených schopností - používáme pro test stored proceduru.

Můj program implementuje TPC-B včetně testů na konzistenci, které prověří správnou funkci databáze, JDBC driveru a implementace testu. Těchto testů si cením, protože když dostanete do ruky neznámou databázi tak si ji můžete prozkoušet zda opravdu splňuje ACID transakce. Požadovaná minimální velikost řádek v tabulkách byla empiricky zjištěna pro všechny podporované databáze kromě Derby. Nepočítal jsem ale do velikosti řádky i indexy (což TPC-B specifikace dovoluje) takže velikost indexů jsou takříkajíc zbytečná data a io operace navíc. Kdybychom soutěžili v reálném TPC-B testu tak bychom pro maximální výkon ještě řádky zkrátili o velikost indexů.

Program je k dispozici pod MIT/X11 licencí (2-bodová BSD) a je hostován na serveru launchpad na rozdíl od mých ostatních projektů které mám na SourceForge. Launchpad je na rozdíl od SF.NET rychlejší, ergonomičtější a spolehlivější. Existující projekty bych na něj ale nepřesouval z důvodů pracnosti importu dat z bug trackerů, downloadů a mailing listů.

Program JDBC TPC-B je koncipován pro spouštění z Java IDE (kupříkladu Eclipse), protože z časových důvodů nebyla ani započata práce na command line rozhraní. Použití v Eclipsu je jednoduché. Stáhnutý tarball dekomprimujete a naimportujete jako Eclipse projekt. Pak budete muset ještě nastavit správně classpath, protože potřebujeme v ní mít JDBC drivery. Program nevyžaduje žádnou knihovnu navíc kromě standardního JRE a JDBC driverů.

V editoru si otevřeme start.java. Nejdůležitější věcí, kterou musíme nastavit je driver pro databázi a JDBC URL databáze. Tyto věci nastavíme tak, že poeditujeme, případně odkomentujeme řádky týkající se naší databáze. Kupříkladu pro Oracle XE to bude vypadat takto:

d = new oracledriver();
d.setJDBCURL("jdbc:oracle:thin:@///XE");

Podobně jako u PGBenchu si musíte vhodně zvolit scale factor, který určuje konstanta SCALE a je to velikost databáze a současně maximální uznatelnou hodnotu tpsB. Obdobně můžeme nastavit i dobu testu BENCHTIME a počet vláken THREADS.

V posledním díle série o TPC testech si ukážeme jak v TPC-B obstály nejčastěji používané databáze.

Verze pro tisk