On 11/18/2014 12:33 AM, Yanrui Hu wrote:
I am working on a evaluation to put db client outside the datacenter and
to know how the network impact on the business.
After several round of testing, I have a question regarding to the two
tps result in stress output.
Test A:
Client and DB server exist in same AWS datacenter.
transaction type: Custom query
scaling factor: 500
query mode: simple
number of clients: 25
number of threads: 25
duration: 600 s
number of transactions actually processed: 54502
tps = 90.814930 (including connections establishing)
tps = 204.574432 (excluding connections establishing)
Test B:
Client and DB server exist in different AWS datacenter (west and east).
transaction type: Custom query
scaling factor: 500
query mode: simple
number of clients: 25
number of threads: 25
duration: 600 s
number of transactions actually processed: 13966
tps = 23.235705 (including connections establishing)
tps = 42.915990 (excluding connections establishing)
Its obviously that both tps become lower if client and server do not
exist in same datacetner since the network connection have more latency.
But I can not explain why the tps that excluding connections
establishing is changed so much.
For my understanding, tps excluding connections establishing get rid of
the time that create socket cost. That means in above two test
cases(only network different), the tps excluding connections
establishing should be very close, right?
Not that I can see from the numbers. In the non-network case you
processed 54,502 transactions over 600s and in the network case 13,966
transactions over 600s. Even if you factor out the connection
establishment you have fewer transactions over the same time period for
the network case. So there is no way the tps can be equivalent. As
others have pointed out this due to the effect of network latency on the
processing of the queries.
You might want to take a look at the Notes section of here:
http://www.postgresql.org/docs/9.3/static/pgbench.html
In particular the different logging options that are available. They may
make it easier to see what is going on.
Because the database is same
and capability is same only network latency is different.
--
Best Regards,
Yanrui Hu (Ray)
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
