David Kerr <dmk@xxxxxxxxxxxxxx> wrote: > Hmm, i'm not following you. I've got 48 cores. that means my > sweet-spot active connections would be 96. Plus your effective spindle count. That can be hard to calculate, but you could start by just counting spindles on your drive array. > Now if i were to connection pool that out to 15 people per > connection, Where did you get that number? We routinely route hundreds of requests per second (many of them with 10 or 20 joins) from five or ten thousand connected users through a pool of 30 connections. It started out bigger, we kept shrinking it until we hit our sweet spot. The reason we started bigger is we've got 40 spindles to go with the 16 cores, but the active portion of the database is cached, which reduces our effective spindle count to zero. > that's 1440 users "total" able to use my app at one time. (with > only 96 actually doing anything). not really great for a web-based > app that will have millions of users accessing it when we're fully > ramped up. Once you have enough active connections to saturate the resources, adding more connections just adds contention for resources and context switching cost -- it does nothing to help you service more concurrent users. The key is, as I mentioned before, to have the pooler queue requests above the limit and promptly get them running as slots are freed. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
