[Pgpool-general] pgpool II performance

[Tatsuo Ishii]

Yes, if you were using PHP, you'd better to use pgpool, rather than
pgp_connect. I heard bad rumors about pgp_connect.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Tatsuo,
> 
> In case of polling ... do you advocate to stay in permanent connection in php 
> with pg_pool ?
> 
> Thanks,
> 
> Le samedi 08 mars 2008, Tatsuo Ishii a écrit :
> > I think you are comapring an apple with an orange.
> >
> > In reality typical PostgreSQL clients repeat the pattern "connect to
> > PostgreSQL, do something, disconnect" (for example web
> > applications). You could add -C option to pgbench to simulate the
> > behavior. Probably you could see how pgpool enhance the performance by
> > using connection pooling.
> >
> > If your application keeps the connection to PostgreSQL, yes pgpool add
> > just some overhead. We have worked hard to minimize it, but it seems
> > very difficult to lower than as it is.
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> >
> > > Thank you for your reply.   I have done some further tests:
> > >
> > > Taking into account possible network problems I ran pgbench on the pgpool
> > > server hitting the db server directly to gauge any network latency
> > > issues:
> > >
> > > postgres at db-2:~$ pgbench -c 20 -t 1000 -h XX.XXX.XX.XXX -p 5432 testdb1
> > > starting vacuum...end.
> > > transaction type: TPC-B (sort of)
> > > scaling factor: 1
> > > number of clients: 20
> > > number of transactions per client: 1000
> > > number of transactions actually processed: 20000/20000
> > > tps = 974.866385 (including connections establishing)
> > > tps = 977.606505 (excluding connections establishing)
> > >
> > > turning off replication and only using pgpool "connection pooling" I
> > > still get a pretty big decrease in performance.
> > > postgres at db-2:~$ pgbench -c 20 -t 1000 -h localhost -p 9999 testdb
> > > starting vacuum...end.
> > > transaction type: TPC-B (sort of)
> > > scaling factor: 1
> > > number of clients: 20
> > > number of transactions per client: 1000
> > > number of transactions actually processed: 20000/20000
> > > tps = 718.794739 (including connections establishing)
> > > tps = 742.188834 (excluding connections establishing)
> > >
> > >
> > > I still think I might have something configured incorrectly.   Is pgbench
> > > not a good tool to benchmark the connection pooling with?
> > >
> > >
> > > Thank you for your time.
> > >
> > > --J
> > >
> > > On Thu, Mar 6, 2008 at 10:46 PM, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> > > > > I'm running Postgres 8.1.11.   Here are the results of a pgbench test
> > > > > pgbench -c 20 -t 1000 testdb
> > > > > starting vacuum...end.
> > > > > transaction type: TPC-B (sort of)
> > > > > scaling factor: 1
> > > > > number of clients: 20
> > > > > number of transactions per client: 1000
> > > > > number of transactions actually processed: 20000/20000
> > > > > tps = 731.350579 (including connections establishing)
> > > > > tps = 732.860160 (excluding connections establishing)
> > > > >
> > > > > I set up another environment with 3 servers 1 pgpool server and 2
> > > >
> > > > masters
> > > >
> > > > > for master-master replication.  Everything on the pgpool functions
> > > > > great
> > > >
> > > > but
> > > >
> > > > > the performance is terrible.   Here are the results of the same
> > > > > pgbench
> > > >
> > > > test
> > > >
> > > > > run on the pgpool cluster.
> > > > > pgbench -p 9999 -c 20 -t 1000 testdb
> > > > > starting vacuum...end.
> > > > > transaction type: TPC-B (sort of)
> > > > > scaling factor: 1
> > > > > number of clients: 20
> > > > > number of transactions per client: 1000
> > > > > number of transactions actually processed: 20000/20000
> > > > > tps = 443.242941 (including connections establishing)
> > > > > tps = 443.912381 (excluding connections establishing)
> > > > > tps = 401.669441 (excluding connections establishing)
> > > > >
> > > > >
> > > > > All four servers have exactly the same hardware configuration.
> > > > >
> > > > > Is this performance loss normal?
> > > >
> > > > Yes.
> > > >
> > > > I think existing shared-nothing-synchronous-replication softwares
> > > > including PGCluster will show more or less same performance.
> > > >
> > > > I should note that while other such replication softwares show the
> > > > performance degration almost propotional to the numbers of PostgreSQL
> > > > servers, pgpool's performance is not worse than 1/2 of PostgreSQL.
> > > >
> > > > Also please note that READ query performance will increase according
> > > > to the numbers of PostgreSQL servers. So you have a chance to get
> > > > performance boost if most of your quries are READ. Of course this may
> > > > vary to the characteristics of load though.
> > > > --
> > > > Tatsuo Ishii
> > > > SRA OSS, Inc. Japan
> >
> > _______________________________________________
> > Pgpool-general mailing list
> > Pgpool-general at pgfoundry.org
> > http://pgfoundry.org/mailman/listinfo/pgpool-general
> 
> 
> 
> -- 
> Hervé Piedvache