Re: [PERFORM] pgbench could not send data to client: Broken pipe

2010-09-09 Thread Greg Smith
Kevin Grittner wrote: In my experience you can expect the response time benefit of reducing the size of your connection pool to match available resources to be more noticeable than the throughput improvements. This directly contradicts many people's intuition, revealing the downside of "gut fee

Re: [PERFORM] pgbench could not send data to client: Broken pipe

2010-09-09 Thread Kevin Grittner
Greg Smith wrote: > Kevin Grittner wrote: >> Of course, the only way to really know some of these numbers is >> to test your actual application on the real hardware under >> realistic load; but sometimes you can get a reasonable >> approximation from early tests or "gut feel" based on experience >

Re: [PERFORM] pgbench could not send data to client: Broken pipe

2010-09-09 Thread Greg Smith
Kevin Grittner wrote: Of course, the only way to really know some of these numbers is to test your actual application on the real hardware under realistic load; but sometimes you can get a reasonable approximation from early tests or "gut feel" based on experience with similar applications. And

Re: [PERFORM] pgbench could not send data to client: Broken pipe

2010-09-09 Thread David Kerr
On Thu, Sep 09, 2010 at 10:38:16AM -0400, Alvaro Herrera wrote: - Excerpts from David Kerr's message of mié sep 08 18:29:59 -0400 2010: - - > Thanks for the insight. we're currently in performance testing of the - > app. Currently, the JVM is the bottleneck, once we get past that - > i'm sure it

Re: [PERFORM] pgbench could not send data to client: Broken pipe

2010-09-09 Thread Alvaro Herrera
Excerpts from David Kerr's message of mié sep 08 18:29:59 -0400 2010: > Thanks for the insight. we're currently in performance testing of the > app. Currently, the JVM is the bottleneck, once we get past that > i'm sure it will be the database at which point I'll have the kind > of data you're tal