Robert, what I'm testing now is 256 users max. The workload is growing
progressively from 1, 2, 4, 8 ... to 256 users. Of course the Max
throughput is reached on the number of users equal to 2 * number of
cores, but what's important for me here - database should continue to
keep the workload! - response time regressing, but the troughput
should remain near the same.
So, do I really need a pooler to keep 256 users working?? - I don't
think so, but please, correct me.
BTW, I did not look to put PostgreSQL in bad conditions - the test is
the test, and as I said 2 years ago PostgreSQL outperformed MySQL on
the same test case, and there was nothing done within MySQL code to
improve it explicitly for db_STRESS.. And I'm staying pretty honest
when I'm testing something.
Rgds,
-Dimitri
On 5/12/09, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, May 12, 2009 at 8:59 AM, Dimitri <dimitrik.fr@gmail.com> wrote:
>> Wait wait, currently I'm playing the "stress scenario", so there are
>> only 256 sessions max, but thing time is zero (full stress). Scenario
>> with 1600 users is to test how database is solid just to keep a huge
>> amount of users, but doing only one transaction per second (very low
>> global TPS comparing to what database is able to do, but it's testing
>> how well its internals working to manage the user sessions).
>
> Didn't we beat this to death in mid-March on this very same list?
> Last time I think it was Jignesh Shah. AIUI, it's a well-known fact
> that PostgreSQL doesn't do very well at this kind of workload unless
> you use a connection pooler.
>
> *goes and checks the archives* Sure enough, 116 emails under the
> subject line "Proposal of tunable fix for scalability of 8.4".
>
> So, if your goal is to find a scenario under which PostgreSQL performs
> as badly as possible, congratulations - you've discovered the same
> case that we already knew about. Obviously it would be nice to
> improve it, but IIRC so far no one has had any very good ideas on how
> to do that. If this example mimics a real-world workload that you
> care about, and if using a connection pooler is just not a realistic
> option in that scenario for whatever reason, then you'd be better off
> working on how to fix it than on measuring it, because it seems to me
> we already know it's got problems, per previous discussions.
>
> ...Robert
>
