John R Pierce
> On 07/03/12 12:34 AM, Craig Ringer wrote:
>> I'm seriously impressed that your system is working under load at
>> all with 800 concurrent connections fighting to write all at once.
>
> indeed, in my transactional benchmarks on a 12 core, 24 thread dual
> xeon x5600 class systems, with 16 or 20 spindle raid10, I find
> somewherre around 50 to 80 database connection threads has the
> highest overall throughput (several thousand OLTP
> transactions/second). this hardware has vastly better IO and CPU
> performance than any AWS virtual machine.
>
>
> as craig suggested, your network threads could put the incoming
> requests into queue(s), and run a tunable number of database
> connection threads that take requests out of the queue and send
> them to the database, and if neccessary, return results to the
> network thread. doing this will give better CPU utilization, you
> can try different database worker thread counts til you hit the
> optimal number for your hardware.
+1
We (at the Wisconsin courts) have definitely found that the best
model for us is to have a separate layer for running database
transactions, with one thread per database connection and each of
those threads pulling from a prioritized FIFO queue into which
*other* layers place requests.
This comes up so often that I threw together a Wiki page for it:
http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
Of course, everyone should feel free to improve the page.
-Kevin