FSM patch - performance test
От | Zdenek Kotala |
---|---|
Тема | FSM patch - performance test |
Дата | |
Msg-id | 48D23EA6.3030601@sun.com обсуждение исходный текст |
Ответы |
Re: FSM patch - performance test
(Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: FSM patch - performance test (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Hi Heikki, I finally performed iGen test. I used two v490 servers with 4 dual core SPARC CPUs and 32GB RAM. I have only one disk and I did not performed any disk I/O optimization. I tested 105 parallel connection and think time was 200ms. See the result: Original: --------- Actual run/snap-shot time: 3004 sec MQThL (Maximum Qualified Throughput LIGHT): 1458.76 tpm MQThM (Maximum Qualified Throughput MEDIUM): 3122.44 tpm MQThH (Maximum Qualified Throughput HEAVY): 2626.70 tpm TRANSACTION MIX Total number of transactions = 438133 TYPE TX. COUNT MIX ---- --------- --- Light: 72938 16.65% Medium: 156122 35.63% DSS: 48516 11.07% Heavy: 131335 29.98% Connection: 29222 6.67% RESPONSE TIMES AVG. MAX. 90TH Light 0.541 3.692 0.800 Medium 0.542 3.702 0.800 DSS 0.539 3.510 0.040 Heavy 0.539 3.742 4.000 Connections 0.545 3.663 0.800 Number of users = 105 Sum of Avg. RT * TPS for all Tx. Types = 64.851454 New FSM implementation: ----------------------- Actual run/snap-shot time: 3004 sec MQThL (Maximum Qualified Throughput LIGHT): 1351.20 tpm MQThM (Maximum Qualified Throughput MEDIUM): 2888.74 tpm MQThH (Maximum Qualified Throughput HEAVY): 2428.90 tpm TRANSACTION MIX Total number of transactions = 405502 TYPE TX. COUNT MIX ---- --------- --- Light: 67560 16.66% Medium: 144437 35.62% DSS: 45028 11.10% Heavy: 121445 29.95% Connection: 27032 6.67% RESPONSE TIMES AVG. MAX. 90TH Light 0.596 3.735 0.800 Medium 0.601 3.748 0.800 DSS 0.601 3.695 0.040 Heavy 0.597 3.725 4.000 Connections 0.599 3.445 0.800 Number of users = 105 Sum of Avg. RT * TPS for all Tx. Types = 66.419466 ---------------------------- My conclusion is that new implementation is about 8% slower in OLTP workload. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
В списке pgsql-hackers по дате отправления: