Zadani:
	Srovnani vykonu databazi Postgresql a Oracle pro aplikaci ccReg.

Reseni:
	Rozdeleni do podcelku:
		- obecne srovnavaci testy
		- testy specializovane na ccReg
			- generovani testovacich dat
			- tvorba historie
			- testy

TODO:
	*) Zkontrolovat jestli sedi orientacni pocty objektu v databazi
	a jejich vzajemne pomery



1. Obecne srovnavaci testy

Bude zajimavy vyzkouset benchmark od uplne nekoho jinyho. Jeden takovy jsem
objevil. Projekt osdb (open source database benchmark) se zabyva tvorbou
benchmarku pro databaze zda se ze na pomerne dobry urovni (puvodne to byl
projekt v ramci firmy COMPAQ nez ho uvolnili pod GPL). Vychazi z nejakych
standardu pro benchmarkovani vykonu databazi. Existuje podpora jak pro
postgresql tak pro oracle (nedavno doplnena). Cisla z techto benchmarku
maji vyznam pouze pro srovnani dvou konkurentu testovanych ve stejnych
podminkach - nevyplivne to zadny absolutni cislo ze stupnice spatny...dobry.
To vyhovuje nasim ucelum.

Trosku podrobneji k OSDB. Test se sklada z nekolika fazi:
	1) mereni rychlosti vytvoreni databaze se vsemi tabulkami
	2) mereni ryclosti nasypani dat do databaze
	3) single user test (selecty, joiny, agregacni funkce, ...)
	4) multi user test (zhruba to samy co single user test obsahove)

Pocet uzivatelu v multi-user testu lze konfigurovat, zrovna tak velikost
databaze. Prozatim jsem vyzkousel u sebe na localhostu na postgresql
s velikosti databaze 40MB a poctem multi useru 10. Vsechny vysledky se
zapisujou do logu, po cca hodine chroustani to dobehlo. Abyste si udelali
obrazek o vystupu, prikladam vypis z logu pro multi-user test:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Executing multi-user tests with 10 user tasks
Mixed IR (tup/sec)      298.20  returned in 5.00 minutes (89460 tuples)
                     sel_1_ncl()        0.01 seconds    return value = 1
             agg_simple_report()        0.92 seconds    return value = 990068766
                mu_sel_100_seq()        0.19 seconds    return value = 0
               mu_sel_100_rand()        0.05 seconds    return value = 0
          mu_mod_100_seq_abort()        0.04 seconds    return value = 0
               mu_mod_100_rand()        0.11 seconds    return value = 0
              mu_unmod_100_seq()        0.04 seconds    return value = 0
             mu_unmod_100_rand()        0.08 seconds    return value = 0
crossSectionTests(Mixed IR)     1.44
           mu_checkmod_100_seq()        0.00 seconds    return value = 100
          mu_checkmod_100_rand()        0.00 seconds    return value = 100
Mixed OLTP (tup/sec)    2170.72 returned in 5.00 minutes (651217 tuples)
                     sel_1_ncl()        0.01 seconds    return value = 1
             agg_simple_report()        7.52 seconds    return value = 990068766
                mu_sel_100_seq()        0.08 seconds    return value = 0
               mu_sel_100_rand()        0.01 seconds    return value = 0
          mu_mod_100_seq_abort()        0.08 seconds    return value = 0
               mu_mod_100_rand()        0.04 seconds    return value = 0
              mu_unmod_100_seq()        0.01 seconds    return value = 0
             mu_unmod_100_rand()        0.00 seconds    return value = 0
crossSectionTests(Mixed OLTP)   7.75
           mu_checkmod_100_seq()        0.02 seconds    return value = 100
          mu_checkmod_100_rand()        0.02 seconds    return value = 100

Multi-User Test 2429.82 seconds (0:40:29.82)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Takhle metoda dava velky mnozstvi cisel (cca 50). Kdybych tvrdil ze vim ted co
vsechny znamenaj tak bych lhal. Ale vsechno se da lehce dohledat a obrazek z
nich si pujde podle myho nazoru udelat celkem slusnej i s tim, ze muzeme
pomerne pekne naky cisla zamaskovat a naky naopak vyzdvihnout - ale nebudu
predbihat vysledky testu.  Uvidime.



2. Testy specializovane na ccReg

Muj puvodni plan byl delat i specializovany testy hrubou silou (tj. treba
100000 insertu do tabulky domain). Tezko cekat jiny vysledky nez u testu
OSDB, ktery dela v podstate to samy (navic sofistikovaneji). Proto navrhuju
ve specifickych testech pro ccReg ponechat pouze sekvence dotazu
charakteristicke pro ccReg.

Test se bude skladat ze 3 fazi, ktere po sobe nemusi nutne nasledovat a
kazda muze byt spustena zvlast. Jednotlive faze si mezi sebou nemusi predavat
zadne jine informace nez jsou primo data v databazi.

	*) Faze generovani dat musi byt spustena aspon jednou pro vytvoreni
	databaze a naliti databaze pocatecnimi daty. Generovani musi
	respektovat pocty objektu a vzajemne pomery, ktere budou specifikovany
	v konfiguracnim souboru.

	*) Faze vytvareni historie v podstate dela to same co posledni faze
	testovani: Provadi operace nad daty a tim tvori historii. Ovsem
	uplatnuji se na ni jina kriteria. Pri vytvareni historie se nemeri
	cas, pouze se kontroluji objemy dat v tabulkach zachycujicich historii
	objektu. Na objem dat v tabulkach historie lze stanovit limity zase
	pomoci konfiguracniho souboru.

	*) Faze testovani provadi ty same operace jako faze vytvareni historie
	ale pracuje odlisnym zpusobem. Zatimco operace pro historii se tvori
	"on the fly", testy jsou dopredu pripravene tak, aby se minimalizoval
	cas straveny v testovacim programu a vse jelo jak na dratku, protoze
	cas se bude merit se vsim vsudy (i s casem stravenym v interpretu
	pythnu). Parametry testovani se budou predavat take v konfiguracnim
	souboru.

Priklad konfiguracniho souboru, ktery je spolecny vsem trem fazim:

	[generator]
	domains  = 500000 # pocet domen k vygenerovani
	messages = 40 # pocet zprav ve fronte na jednoho registratora
	# atd.

	[history]
	domains = 10000000 # pocet domen v historii
	# atd.

	[test]
	clients = 20 # pocet paralelnich procesu vysilajicich pozadavky
	steps = 1000000 # pocet testovacich iteraci (1 iterace = 1 operace)
	# atd.

Zbyva vysvetlit jak je mozne ze si jednotlive faze mezi sebou nebudou muset
predavat zadny soubor s pomocnymi informacemi o vazbach mezi domenama,
kontakty a nssety. Na ukor casu lze vzdycky tyto informace vydolovat primo
z databaze. Ve fazi historie je dost casu na vsechno, ci-li zjistovat
si tyto pomocne informace (jestli muze byt kontakt nebo nsset smazan atd.)
za behu neni problem. A ve fazi testovani name to zas nevadi, protoze
i v realnem zivote bude dochazet k situacim ze se nekdo napr. pokousi smazat
domenu ktera neexistuje a podobne. Nicmene list s operacemi se vytvori
predem, preda se k vykonani jadru testovaciho programu. Nasleduje podrobnejsi
popis jednotlivych fazi.

2.1 Generovani testovacich dat

Orientacni hodnoty pro pocet dynamicky generovanych objektu v databazi:

	pocet aktivnich domen         ...    500 000
	pocet domen v historii        ... 10 000 000
	pocet aktivnich kontaktu      ...  1 000 000
	pocet kontaktu v historii     ... 20 000 000
	pocet aktivnich nssetu        ...    400 000
	pocet nssetu v historii       ...  8 000 000
	pocet hostu v nssetu          ...          2
	pocet zprav na 1 registratora ...         40

Orientacni pocet objektu generovanych staticky (jejich pocet se nemeni):

	pocet registratoru  ... 20
	pocet zon           ... 3

Pomer poctu domen vzhledem k rozdeleni do zon je:

	enum domeny : klasicky domeny   =   1 : 5

Jako prvni se vygeneruji staticke objekty (registratori, zony, ...). Dale se
zacnou generovat dynamicke objekty.  Generator si sam pro sebe v prubehu
generovani udrzuje informaci o vazbach mezi objekty, tato informace je vsak po
ukonceni generatoru ztracena.  Generator postupne generuje objekty v tomto
poradi: kontakty, nssety, domeny a ostatni veci (napr. zpravy). Pocet
vygenerovanych objektu je presne stanovem v konfiguracnim souboru. U objektu
rozdeluje jejich atributy na nepodstatne a podstatne z hlediska vazeb.

	- Nepodstatne atributy (napr. adresa u kontaktu) jsou vyplnene
	  nahodnymi znaky o nahodne delce (v ramci predepsanych mezi) a
	  generator se o ne nijak dale nestara.
	  
	- Podstatne atributy souvisi s cizimi klici v tabulkach. Generator
	  si udrzuje povedomi o existujicich atributech, ktere pouziva
	  pri tvorbe dalsich objektu, ktere na techto atributech zavisi.
	  Mezi podstatne atributy patri: fqdn u domeny, handle u kontaktu,
	  handle u nssetu. Parovani kontakt-nsset, kontakt-nsset-domain
	  se deje nahodnym vyberem s rovnomernym rozlozenim ze seznamu
	  vsech relevantnich objektu. Tim se dosahne rovnomerneho rozlozeni
	  vazeb mezi objekty. Je otazka jestli to odpovida skutecnosti nebo
	  jestli je v praxi castejsi napr. nekoli kontaktu ktere na sebe
	  maji navazano mnoho domen a ostatni objekty po malu domen
	  (takovy zhluky). Nicmene je to nejjednodusi cesta.

Posledni se vygeneruji zpravy do tabulky zprav. Historie je prazdna. Tabulka
akci obsahuje pouze akce vytvoreni, ktere se doposud uskutecnily.


2.2 Tvorba historie

Tvorba historie laicky receno spociva v zasmodrchovani stavu objektu -
vykonavani ruznych operaci nad nimi. Historie pouziva pouze transformacni EPP
funkce, ktere meni stav objektu. Na nahodnych objektech a v nahodnem poradi
vola vsechny mozne tranformacni funkce:

	objekt domena - create, update, renew, transfer, delete
	objekt nsset - create, update, transfer, delete
	objekt contact - create, update, delete.

Update funkce updatuji pouze jeden stanoveny atribut objektu pro jednoduchost.
Tam kde je potreba pouzit odkaz na cizi objekt (napr. vytvoreni domeny 
potrebuje nsset), je identifikator objektu nahodne vytazen z databaze.
Tvorba historie postupne ustava s tim jak se postupne zaplni tabulky historie
pro jednotlive objekty podle limitu stanovenych v konfiguraku.


2.3 Test

Test tak jako tvorba historie je nahodna prochazka pres objekty a pripustne
operace nad nimi. Stoji na tom, ze takto nahodne vygenerovana posloupnost
prikazu a objektu je reprodukovatelna (generatoru nahodnych cisel se zada
seed) a ze oba srovnavane systemy zacinaji s databazemi ve stejnem stavu
(zajisti budto primo generator a historie nebo se zajisti dumpem/restorem
pred zacatkem testu). Vygeneruje se sada operaci nad objekty. Pak se nahodny
charakter vytrati a postupuje se postupne uz pouze podle predepsaneho seznamu
operaci. Neni chybou pokud seznam operaci obsahuje operaci, ktera nelze
provest, protoze to se stava i v realnem provozu. To osetruji predrazene
selecty, tak jako v ccRegu tak i zde. Vyskyt neuskutecnenych operaci pri
tak velkem testovacim vzorku dat, by mel byt mensi nez tech, co se povedou.
To taky odpovida realne situaci.

TODO:
	Presne vycucnout pouzivane sekvence SQL dotazu v ccRegu pro jednotlive
	EPP operace. Mozna by to nemuselo byt tady ale protoze je to
	mechanicka prace, ale primo uz v programu.

Pri paralelnim behu vice procesu pozadavku, nemuzeme zajistit
reprodukovatelnost, protoze zprehazeni poradi operaci muze zpusobit ruzne
vysledky. Proto musi paralelni testy bezet dost dlouho na to, aby se odchylky
zprumerovali, a vyslo nejaky slusny cislo, a nejlip jeste nekolikrat a z toho
vypocist prumer.



3. Rozjimani :)

Otazka jestli nepouzit prece jen Ccko?

	Cim rychlejsi to bude tim spis budeme merit cas straveny v databazi a
	ne v interpretu. Python je vyhlasen svou pomalosti. Otazka jestli
	prece jen nezvolit Ccko jako implementacni jazyk testu. Merit dotazy
	jednotlive nema smysl, nadelalo by se podle me vice nepresnosti
	zaokrouhlovanim (moc male casy) nez se nadela zapoctenim okolniho kodu
	testeru. Na druhou stranu bude to pomalejsi psat to v Ccku...

Ma Jara k dispozici nejakou SQL davku, ktera vytvori pocatecni rozlozeni
databaze se statickymi daty? Urcite by se hodilo i pro jiny ucely nez
testovani.

Nabizi se aby faze history a test sdileli spolecnou knihovnu EPP operaci, kde
by byly nafrkany uz dotazy tak jak se vyskytuji v ccRegu.
