informix benchmark question?
Posted in 2023
Topics: Performance & Tuning, Connectivity: ESQL/C, 4GL & Embedded SQL, Versions, Editions & End-of-Life
HI, I download the program from below website. and want to do some compare testing in different hardware. https://sourceforge.net/projects/iiug-software-repository/files/ESQL/tpc-c-ifmx/ and I setup those program successful in my thinkpad. and got the first round testing result . SELECT OPTION: 6 Computation of performance test done on 2023-05-09 at 04:48:13 for 5 warehouses, 10 terminals. Database engine IBM Informix Dynamic Server Version 12.10.FC10 Benchmark pace Human Start of measurement interval: 0.166783 m End of measurement interval: 2.167300 m COMPUTED THROUGHPUT: 82.979 tpmC-uva using 5 warehouses. 395 Transactions committed. NEW-ORDER TRANSACTIONS: 166 Transactions committed into measurement interval. Total transactions: 166. Percentage of Total transactions: 42.025% Percentage of "well done": 87.952% Response time (min/avg/max/90th): 0.077 / 2.107 / 13.140 / 6.240 Percentage of rolled-back transactions: 0.000% . Average number of items per order: 9.373 . Percentage of remote items: 0.707% . Think time (min/avg/max): 0.000 / 6.849 / 29.000 PAYMENT TRANSACTIONS: 168 Transactions committed into measurement interval. Total transactions: 168. Percentage of Total transactions: 42.532% Percentage of "well done": 100.000% Response time (min/avg/max/90th): 0.002 / 0.461 / 2.392 / 1.240 Percentage or remote transactions: 9.524% . Percentage of customers selected by C_ID: 36.905% . Think time (min/avg/max): 0.000 / 6.179 / 27.000 Continue... ORDER-STATUS TRANSACTIONS: 18 Transactions committed into measurement interval. Total transactions: 18. Percentage of Total transactions: 4.557% Percentage of "well done": 100.000% Response time (min/avg/max/90th): 0.115 / 0.725 / 2.252 / 2.040 Percentage of customers selected by C_ID: 27.778% . Think time (min/avg/max): 1.000 / 10.333 / 31.000 Continue... DELIVERY TRANSACTIONS: 15 Transactions committed into measurement interval. Total transactions: 15. Percentage of Total transactions: 3.797% Percentage of "well done": 80.000% Response time (min/avg/max/90th): 0.544 / 2.653 / 12.654 / 6.760 Percentage of execution time < 80s : 100.000% Execution time min/avg/max: 0.674/0.674/0.674 No. of skipped districts: 0 . Percentage of skipped districts: 0.000%. Think time (min/avg/max): 0.000 / 5.533 / 14.000 Continue... STOCK-LEVEL TRANSACTIONS: 28 Transactions committed into measurement interval. Total transactions: 28. Percentage of Total transactions: 7.089% Percentage of "well done": 82.143% Response time (min/avg/max/90th): 0.003 / 11.260 / 35.111 / 32.000 Think time (min/avg/max): 0.000 / 7.107 / 20.000 Continue... >> TEST FAILED Transactions response time do not follow the standard requirements. ================= I have below question. 1) What is the standard requirements? Do it mean the reponse time is too large? 2) How to calculate the transaction per second? thanks for your time. lu chuan ------------------------------ chuan lu ------------------------------
First - the easy one, "How to calculate the transaction per second" The TPC-C benchmark reports number of New Order transactions per minute (tpm-C), the remaining 4 transaction types are not reported. To get "transactions per second" - you simply divide the reported number by 60 However that does not give total transactional load, only the most important (which is - how many new orders can be placed in a unit of time, nobody really cares about "stock level" ...) For the standard requirements - you will have better luck either visiting tpc.org (they have PDF with descriptions of this benchmark) or checking the source code - which will allow you to see what conditions failed. Having said that - running benchmark is not just getting the kit and expecting that everything works right out of the box. Couple of things to look for are: 1. you need to have enough capability on the benchmark client to drive the server (and adequate network setup) 2. there should exist a client configuration which is capable of driving system running the server to 100% of CPU utilization. Without (at least) these conditions - it's unclear what you measure and how to compare the results. Pretty much any system can do one transaction per minute (or per second), the idea is to get maximum possible result given a certain configuration. Hence - the requirement of at least achieving 100% CPU utilization on the system running the RDBMS. Good luck! ------------------------------ Vladimir Kolobrodov ------------------------------