>>> "Jignesh K. Shah" <J.K.Shah@xxxxxxx> wrote: > Rerunning similar tests on a 64-thread UltraSPARC T2plus based > server config > (IO is not a problem... all in RAM .. no disks): > Time:Users:Type:TPM: Response Time > 60: 100: Medium Throughput: 10552.000 Avg Medium Resp: 0.006 > 120: 200: Medium Throughput: 22897.000 Avg Medium Resp: 0.006 > 180: 300: Medium Throughput: 33099.000 Avg Medium Resp: 0.009 > 240: 400: Medium Throughput: 44692.000 Avg Medium Resp: 0.007 > 300: 500: Medium Throughput: 56455.000 Avg Medium Resp: 0.007 > 360: 600: Medium Throughput: 67220.000 Avg Medium Resp: 0.008 > 420: 700: Medium Throughput: 77592.000 Avg Medium Resp: 0.009 > 480: 800: Medium Throughput: 87277.000 Avg Medium Resp: 0.011 > 540: 900: Medium Throughput: 98029.000 Avg Medium Resp: 0.012 > 600: 1000: Medium Throughput: 102547.000 Avg Medium Resp: 0.023 I'm wondering about the testing methodology. If there is no I/O, I wouldn't expect performance to improve after you have all the CPU threads busy. (OK, so there might be some brief blocking that would make the optimal number of connections somewhat above 64, but 1000???) What's the bottleneck which allows additional connections to improve the throughput? Network latency? I'm a lot more interested in what's happening between 60 and 180 than over 1000, personally. If there was a RAID involved, I'd put it down to better use of the numerous spindles, but when it's all in RAM it makes no sense. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
