V p°edchozφch dφlech databßzovΘ abecedy jsme uvedli °adu pojm∙ t²kajφcφch se paralelnφho zpracovßnφ transakcφ. Lze tuÜit, ₧e odhadnout v²kon transakΦnφho zpracovßnφ je obtφ₧nΘ. V pr∙b∞hu Φasu, kdy transakΦnφ systΘmy dosp∞ly od naivnφch °eÜenφ k pokroΦilejÜφm, se objevila °ada testovacφch systΘm∙ (benchmarks), kterΘ dovolujφ u₧ivateli porovnat transakΦnφ systΘmy od r∙zn²ch v²robc∙. Pod termφnem benchmark si m∙₧eme p°edstavit jist² etalon umo₧≥ujφcφ n∞jakΘ porovnßnφ. V software jde o p°edpis mno₧iny m∞°enφ, kterΘ je nutnΘ provΘst, aby mohla b²t vyhodnocena n∞jakß vlastnost software, obvykle v²kon. Existujφ tedy nejen testovacφ systΘmy pro m∞°enφ transakΦnφho pracovßnφ, ale nap°. i pro zpracovßnφ dotaz∙ a dalÜφ. Jim Gray, tv∙rce p°φruΦky v∞nujφcφ se testovacφm systΘm∙m (The Benchmark Handbook) z r. 1991, doporuΦuje aby testovacφ systΘm:

• relevantn∞ reprezentoval testovanou domΘnu,
• byl p°enositeln², tj. jednoduÜe implementovateln² na mnoha r∙zn²ch systΘmech a architekturßch,
• byl Ükßlovateln², tj. m∞l by b²t aplikovateln² na menÜφ i v∞tÜφ systΘmy,
• byl jednoduch²m tj. srozumiteln² a dob°e dokumentovan².

Nejslavn∞jÜφ takov² systΘm ve sv∞t∞ databßzφ je oznaΦovßn jako TPC-A. TPC-A je test standardizovan² Konsorciem TPC (Transaction Processing Performance Council), kterΘ zahrnuje cca 50 v²robc∙ (v roce 1992 mezi n∞ pat°ily firmy jako nap°. IBM, ORACLE, INGRES). P∙vodn∞ Ülo o test Debit/Credit publikovan² v Φasopise Datamation v r. 1985. Konsorcium definovalo jeÜt∞ dalÜφ testovacφ systΘmy TPC A, TPC B, TPC C a TPC-D pokr²vajφcφ mnoho r∙zn²ch p°φpad∙ hardwarov²ch konfiguracφ, typ∙ transakcφ atd. Pomocφ t∞chto systΘm∙ se m∞°φ v²kon v poΦtu transakcφ za sekundu (t/s), resp. za hodinu (u TPC-D ale i pom∞r cena/v²kon a dalÜφ parametry). Je z°ejmΘ, ₧e ₧ßdn² ze souΦasn²ch v²robc∙ transakΦnφho software nepouÜtφ na trh systΘm, bez publikace v²sledk∙ provedenφ p°φsluÜnΘho testu.

Test TPC-A modeluje jednoduchΘ bankovnφ transakce pomocφ Φty°ech tabulek (viz Tab. 1). Obecn∞ lze pomocφ TPC-A testovat i nerelaΦnφ systΘmy, tj. mφsto tabulek m∙₧e jφt o soubory, nicmΘn∞ p°edpoklßdß se spln∞nφ vlastnostφ ACID a tedy takto nelze testovat ka₧d² jednoduch² systΘm pro zpracovßnφ soubor∙.

Velikosti tabulek jsou uzp∙sobeny p°edpoklßdanΘmu zatφ₧enφ provozu do 100 t/s. Transakce jsou vÜechny identickΘ - p°edpoklßdß se p°iΦtenφ Φßstky Delta (zßpornΘ Φφslo) k ·Φtu v danΘ poboΦce pro danou pokladnu. Jde vlastn∞ o UPDATE atributu Z┘STATEK po v²b∞ru pen∞z a to ve t°ech tabulkßch - ┌Φet, Pokladna, PoboΦka, tak₧e se jednß o 3 aktualizace. Dßle se aktualizuje Historie p°idßnφm zßznamu, kter² dokumentuje pohybu na ·Φtu. Takovou transakci budeme dßle naz²vat V▌B╠R.

Vznik transakce se p°edpoklßdß na terminßlu se vstupem 100 Byte (hodnoty pro ╚φslo_·Φtu, ID_pokladny, ID_poboΦky, Delta). Hodnoty vstupu a rovn∞₧ tak i °ßdky v tabulkßch jsou generovßny nßhodn∞. V testu se potom zkouÜφ paralelnφ provoz takov²ch transakcφ.

DalÜφ testy se t²kajφ garance vlastnostφ ACID. Nap°. test na izolaci transakce vychßzφ ze spuÜt∞nφ transakce V▌B╠R, p°ed COMMIT se spustφ druhß takovß transakce a podle jistΘho scΘnß°e se testuje, zdali sprßvn∞ probφhß Φekßnφ a je-li korektnφ v²sledek. Testy na trvanlivost zase simulujφ r∙znΘ chyby a ov∞°ujφ, zdali se zm∞ny sprßvn∞ promφtajφ do denφku transakcφ atd.

Zam∞°me se na chvφli podrobn∞ji na v²konov² test. P°edpoklßdß se, ₧e mezi dv∞ma u₧ivatelsk²mi po₧adavky na jednom terminßlu uplyne v pr∙m∞ru 10 s. Tento cyklus se sklßdß z doby odezvy a Φasu na p°em²Ülenφ u₧ivatele. Je-li jeden u₧ivatel, pak doba odezvy je mnohem menÜφ ne₧ 1 s, nicmΘn∞ se zvyÜujφcφm se poΦtem u₧ivatel∙ se provoz zpomaluje. Prakticky test vypadß tak, ₧e se zaΦne s jist²m poΦtem terminßl∙ (samoz°ejm∞ jejich simulacφ), ka₧d²ch 10 s se generuje dalÜφ transakce. Pak se zvyÜuje poΦet u₧ivatel∙ a₧ se dosßhne doby odezvy ne v∞tÜφ ne₧ 2s u 90% z nich. Toto pravidlo se naz²vß kritΘrium pro dobu odezvy u TPC-A.

P°i m∞°enφ se pak musφ dosßhnout jakΘhosi vyvß₧enΘho stavu, kdy je toto kritΘrium p°i danΘm poΦtu paralelnφch u₧ivatel∙ spln∞no. Trvßnφ odpovφdajφcφho ΦasovΘho intervalu je minimßln∞ 15 min. a ne vφce ne₧ 1 hodina.

Na zßklad∞ TPC-A je mo₧nΘ odhalit ô·zkß hrdlaö transakΦnφho systΘmu p°edevÜφm ve t°ech oblastech:

• uzamykßnφ objekt∙
• zapisovßnφ do denφku transakcφ
• pou₧φvßnφ buffer∙.

Nap°. uzamykßnφ strßnek (a ne °ßdk∙ tabulek), tak jak je obvyklΘ u °ady databßzφ, znaΦn∞ sni₧uje v²kon transakΦnφho systΘmu pod TPC-A. M∙₧e zap°φΦit, ₧e v²kon je °ßdov∞ pouze n∞kolik desφtek TPS.

Co se t²Φe zßpis∙ do denφku transakcφ, problΘm je s p°φstupem na disk, kter² je omezen, °ekn∞me v pr∙m∞ru 40 I/O operacemi za s. Proto₧e s ka₧d²m COMMIT transakce musφ b²t proveden zßpis do denφku, zdßlo by se, ₧e nem∙₧e b²t provedeno vφce ne₧ 40 t/s. ╪eÜenφm je, ₧e denφkov² buffer obsahuje zßznamy pro vφce transakcφ.

Uklßdßnφ populßrnφch strßnek do vnit°nφ pam∞ti m∙₧e takΘ podstatn∞ zv²Üit v²kon transakΦnφho provozu. P°edstavme si pod populßrnφ strßnkou strßnku z disku s dostateΦn∞ mal²m intervalem mezi dv∞ma p°φstupy u₧ivatel∙. Jim Gray a Franco Putzolu v r. 1987 dosp∞li k zßv∞ru, ₧e tento dostateΦn∞ mal² interval je 5 min. Tedy je-li doba mezi dvojφm pou₧itφm jednΘ strßnky v∞tÜφ ne₧ 5 min., je mo₧nΘ ji odeslat na disk a naopak. Na jednΘ stran∞ m∙₧eme zvyÜovat vnit°nφ pam∞¥ pro pou₧itφ jako buffery pro populßrnφ strßnky, na druhΘ stran∞ m∙₧eme po₧adovat vφce disk∙ pro paralelnφ Φtenφ strßnek do vnit°nφ pam∞ti (zv²Üφ se poΦet I/O operacφ za sekundu). Je z°ejmΘ, ₧e rozhodovßnφ o velikostech buffer∙ pak souvisφ s cenami obou typ∙ pam∞tφ. Pravidlo 5 minut lze zd∙vodnit v²poΦty, kterΘ vyva₧ujφ cenu pot°ebnΘ vnit°nφ a vn∞jÜφ pam∞ti.

Na zßklad∞ poΦtu t/s (v anglick²ch textech se uvßdφ TPS) se takΘ poΦφtajφ dalÜφ ukazatelΘ, jako nap°.$COST/TPS. Jde o podφl p∞tiletΘ ceny celΘho systΘmu (software a hardware vΦetn∞ ·dr₧by) na jednu transakci.

Zatφmco test TPC B jen o n∞co vylepÜuje TPC-A (p°idßvß k TPC-A transakci jeden v²b∞r dat na zßklad∞ podmφnky v²b∞ru), s TPC C se dostaneme do realistiΦt∞jÜφho prost°edφ. Test obsahuje on-line i dßvkovΘ transakce, dßle realistickΘ prvky jako jsou ruÜenφ transakcφ, fronty transakcφ. TPC-C ji₧ v∙bec nesouvisφ s TPC-A. Transakce jsou 10x slo₧it∞jÜφ ne₧ v TPC A, tj. jsou 10x pomalejÜφ na stejnΘm hardware. Jeho databßze se sklßdß z 9 tabulek a slo₧itostφ transakcφ se sna₧φ simulovat slo₧it² OLTP systΘm. TPC C byl podobn∞ jako TPC-A zlepÜen na standard Jeho v²sledky se ji₧ uvßd∞jφ v poΦtu transakcφ za minutu, t./min.

V roce 1995 v b°eznu se objevil TPC-D pojednßvajφcφ o poΦtu transakcφ za hodinu, kter² je urΦen pro provoz na Ükßlovan²ch databßzφch (30 GByte, 100 GByte, 300 GByte, ...)

P°ipome≥me, ₧e zmφn∞nΘ TPC A a B vychßzejφ z typick²ch jednoduch²ch bankovnφch transakcφ. D∙vod je historick² - prvnφ transakΦnφ systΘmy byly vyvinuty prßv∞ pro bankovnφ aplikace. ╪ada dalÜφch pou₧itφ transakΦnφch systΘm∙ oficißlnφmi testy je nepokryta, testovßnφ je souΦßstφ kuchyn∞ jednotliv²ch v²robc∙ a je pro r∙znΘ p°φpady st∞₧φ porovnatelnΘ. P°φpadn∞ jsou pou₧ity sice znßmΘ testy, ale nestandardizovanΘ. Pat°φ mezi n∞ nap°. tzv. Wiskonsin benchmark (mß pevnou mno₧inu 32 dotaz∙ pro m∞°enφ v²konu dotazovacφho re₧imu), CITY benchmark pro m∞°enφ transakΦnφho zpracovßnφ na velk²ch databßzφch, AS3AP a dalÜφ. VeÜkerΘ ·daje o TPS a pom∞ru cena/v²kon je proto nutnΘ brßt s rezervou a klßst si otßzku, za jak²ch podmφnek skuteΦn∞ platφ.