From: Jorge Montero <jorge_montero@homedecorators.com>
To: Harpreet singh Wadhwa <harpreet@openbravo.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Need help in performance tuning.
Date: Fri, 09 Jul 2010 11:44:12 -0500
Message-ID: <4C370B8C.2E1C.0042.0@homedecorators.com> (raw)
In-Reply-To: <AANLkTimrWRtnEzRFtWAMwuL2AccFGJFhgc-zsDtsY5Bg@mail.gmail.com>
References: <AANLkTiknhZhKtGDidBsMWtPJpRgln9DrrsCebCEYk5XE@mail.gmail.com>
<4C369346.6010501@postnewspapers.com.au>
<AANLkTin4Q4APRnbJ85FRasU7n8LuhKibKYcGnexsEbTt@mail.gmail.com>
<8760.1278650566@sss.pgh.pa.us>
<4C36D537.1090709@postnewspapers.com.au>
<AANLkTimrWRtnEzRFtWAMwuL2AccFGJFhgc-zsDtsY5Bg@mail.gmail.com>
If your app is running under Tomcat, connection pooling is extremely easy to set up from there: It has connection pooling mechanisms built in. Request your db connections using said mechanisms, instead of doing it manually, make a couple of changes to server.xml, and the problem goes away. Hundreds, if not thousands of concurrent users might end up running with less than 10 connections.
>>> Harpreet singh Wadhwa <harpreet@openbravo.com> 7/9/2010 3:55 AM >>>
Thanx you all for the replies.
I got a gist on where should I head towards
like I should rely a bit on postgres for performance and rest on my
tomcat and application.
And will try connection pooling on postgres part.
And if I come back for any query (related to this topic) then this
time it will be more precise (with real time data of my testing). ;-)
Regards
haps
On Fri, Jul 9, 2010 at 1:22 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 09/07/10 12:42, Tom Lane wrote:
>> Samuel Gendler <sgendler@ideasculptor.com> writes:
>>> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
>>> <craig@postnewspapers.com.au> wrote:
>>>> If you're not using a connection pool, start using one.
>>
>>> I see this issue and subsequent advice cross this list awfully
>>> frequently. Is there in architectural reason why postgres itself
>>> cannot pool incoming connections in order to eliminate the requirement
>>> for an external pool?
>>
>> Perhaps not, but there's no obvious benefit either. Since there's
>> More Than One Way To Do It, it seems more practical to keep that as a
>> separate problem that can be solved by a choice of add-on packages.
>
> Admittedly I'm relatively ignorant of the details, but I increasingly
> think PostgreSQL will need a different big architectural change in the
> coming years, as the typical performance characteristics of machines
> change:
>
> It'll need to separate "running queries" from "running processes", or
> start threading backends, so that one way or the other a single query
> can benefit from the capabilities of multiple CPUs. The same separation,
> or a move to async I/O, might be needed to get one query to concurrently
> read multiple partitions of a table, or otherwise get maximum benefit
> from high-capacity I/O subsystems when running just a few big, expensive
> queries.
>
> Otherwise I'm wondering if PostgreSQL will begin really suffering in
> performance on workloads where queries are big and expensive but there
> are relatively few of them running at a time.
>
> My point? *if* I'm not full of hot air and there's some truth to my
> blather above, any change like that might be accompanied by a move to
> separate query execution state from connection state, so that idle
> connections have a much lower resource cost.
>
> OK, that's my hand-waving for the day done.
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jorge_montero@homedecorators.com, harpreet@openbravo.com
Subject: Re: Need help in performance tuning.
In-Reply-To: <4C370B8C.2E1C.0042.0@homedecorators.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox