FSM patch - performance test

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: FSM patch - performance test
Date: 2008-09-18 11:42:30
Message-ID: 48D23EA6.3030601@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-09-18 11:47:19 Re: FSM patch - performance test
Previous Message Greg Stark 2008-09-18 11:40:17 Re: Adding new flags to XLogRecord