Your SlideShare is downloading. ×
PGPool-II Load testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PGPool-II Load testing

1,133
views

Published on

Ahsan Hadi's presentation from PG Con 2014 in Ottawa

Ahsan Hadi's presentation from PG Con 2014 in Ottawa

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,133
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. © 2013 EnterpriseDB Corporation. All rights reserved. 1 pgpool-II load testing Muhammad Usama May 7, 2014
  • 2. © 2014 EnterpriseDB Corporation. All rights reserved. 2 Goals and objectives  Stress testing  Load balancing / Statement Routing testing  Performance testing compared with PG running on single machine  Cluster stability testing
  • 3. © 2014 EnterpriseDB Corporation. All rights reserved. 3 Hardware/Software configuration  Large amazon instances (15GB Ram with 4 2.5GHz intel Xeon)  PostgreSQL 9.3.2  pgpool-II version 3.3.3  Pgbench (benchmarking tool)  75% read and 25% write load (workload)
  • 4. © 2014 EnterpriseDB Corporation. All rights reserved. 4 Pgpool Cluster setup
  • 5. © 2014 EnterpriseDB Corporation. All rights reserved. 5 pgbench script (read intensive) set nbranches :scale set ntellers 10 * :scale set naccounts 100000 * :scale setrandom aid 1 :naccounts setrandom bid 1 :nbranches setrandom tid 1 :ntellers setrandom delta -5000 5000 BEGIN; UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); END;
  • 6. © 2014 EnterpriseDB Corporation. All rights reserved. 6 pgbench script cont… setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid; setrandom aid 1 :naccounts SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
  • 7. © 2014 EnterpriseDB Corporation. All rights reserved. 7 Test methodology  Automated test script  Performs fresh initdb for every test & executes each test 3 times  20 min run for each test  Test with 300, 1000 and 2000 scale factors  Median value of tps  Ensures repeatable results
  • 8. © 2014 EnterpriseDB Corporation. All rights reserved. 8 1000 Clients with 1000 and 2000 SF
  • 9. © 2014 EnterpriseDB Corporation. All rights reserved. 9 300 Clients with 300,1000,2000 SF
  • 10. © 2014 EnterpriseDB Corporation. All rights reserved. 10 100 Clients with 100,300,1000,2000 SF
  • 11. © 2014 EnterpriseDB Corporation. All rights reserved. 11  Horizontal read scalability. Addition of read replicas increase performance for large size databases.  Better performance when database size increases then memory. No performance gain for smaller databases which fits in memory  Writes go to primary server and reads are load balanced across the replicas.  Performance is not so good with prepared protocol. Doesn't crash but gives negligible performance gain.