Vlákno názorů ke zprávičce IBM DB2 9.7 dosáhla prvenství v TPC-C

Co na to rici nez treba – http://www.c0t0d0s0.org/archives/6846-Arms-race.html

Ty response times jsou irelevantni u tohodle testu ktery byl zameren na co nejmensi cenu za transakci. Navic by ten rozdil cinil jen 10%, coz je pro srovnani s oracle irelevantni, oracle by to projel tak jako tak.
Kdyz se podivame na ten Orakl http://tpc.org/results/individual_results/Sun/Sun_T5440_TPC-C_Cluster_ES_122309_v2.pdf tak vidime ze Orakl podvadel nekolikrat.
1. spatne pocitana cena – licence pronajata jen na 3 roky.
2. vykon db drzel jen po 7,32 sekund, zadny checkpoint. Tedy zhruba jen nez zaplnil db buffery. IBM drzelo vykon po 2 hodiny.

By me zajimalo, kde jste vykalkuloval tech 10%, a znam reakce IBM na puvodni benchmark. Ale jinak neresim, kdo vice „tuningoval“ vysledky nesmyslneho benchmarku, me spise bavi, jak si ted Oracle a IBM vzajemne ukazuji, kdo je „vetsi“ a co vse pro to udelaji :-)
Predpokladam, ze oba vime, ze realna nasazeni jsou stavena trosku jinak :-)

8,95 vs 10,36 z je neco pres 10%.
IBM aby vyhrala TPC-C se nemusi vubec nejak specialne namahat. Vsimnete si ze tenhle system byl staveny tak aby byl levny. Pokud chcete vetsi vykon – tak to neni absolutne zadny problem, proste koupite lepsi zelezo. To jsme porad ale na POWER/AIX/DB2 a to neni u ibm zadna highend platforma, to je bezne zelezo co se pouziva.
Pokud chcete opravdu highend tak vyrazte na i5/OS co ma DB2 v kernelu, ta ma mnohem lepsi vykon per CPU nez ta unixova. A v neposledni rade tu mame System Z a jeho sadu databazi DB2, IMS (vyrazne rychlejsi pro transakcni zpracovani nez DB2} a TPF (vyrazne rychlejsi nez IMS). IMS je pro nektere workloady az 10× rychlejsi nez DB2. Mne treba IMS delalo kdyz jsem to testil asi 90k transakci/sec a na stejnem HW delala db2 neco lehce pres 20k/sec. IMS ale neni rozhodne levny software. Na mainframech se jede IMS pro transakce a DB2 pro data warehouse.
TPC-C je show pro divaky, pouziva se to k podpore prodeje. Kdyz potrebujete nejaky system podporit, vyhrajete s nim TPC-C a mate tak 2–3 roky o objednavky postarano. Proto se taky IBM nesebralo ten vysledek Oraclu okamzite ackoliv mohlo, asi mesic po publikovanem vysledku od Oraclu jsem mel na stole benchmark od IBM kde byli o 30% lepsi kdyz taky pouzili SDD disky. Ale proste nebyla vhodna doba aby s tim sli ven. Jeste tu mam vysledky testu pro DB2 9.8, coz je shared disk cluster edice, to vypada proti Oracle RAC taky velmi zajimave.

Spatne jsem pochopil, co myslite temi 10%. Skoda, ze nemate odvahu diskutovat s Joergem Moellenkampem, docela me prekvapil, kdyz vam to tu okomentoval :-)
Ano, muzeme zvedat vykonost vetsimi stroji. A muzeme si honit vykonost per-CPU. A furt to nerekne nic o tom, ktere nasazeni bude pro danou aplikaci lepsi. Tam jsou to realne testy, realne vypocty.
Jinak vhodna doba bude rozhodne v prubehu OpenWorldu, kde jinde by se IBM melo snazit zastinit Oracle marketing show.

Mate chybu v interpretaci toho dokumentu. Vykon db nedrzel 7.32 sekundy, ale 7320 sekund (oddelovaci carka zde ma jiny vyznam). Takze zhruba tez 2 hodiny.

Sorry … i have to write in English, i just saw this message and translated it with google translate. I ask for you apologize to be not able to answer in your language.
1. The difference in reaction times is significant. When you allow longer response times you put a different load on the system, thus yielding an higher transaction count. Queuing theory mandates this …
2. The , is not the decimal point, it's a thousands seperator … thus we don't talk about 7 seconds, we talk about 7320 seconds, thus 122 minutes, thus a little bit over two hours. That's similar to the measurement interval of the IBM result.