X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 31EFC9DC82D for ; Mon, 20 Feb 2006 20:13:50 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 11698-09 for ; Mon, 20 Feb 2006 20:13:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from peufeu.com (unknown [82.67.9.10]) by postgresql.org (Postfix) with ESMTP id 9C3D99DC805 for ; Mon, 20 Feb 2006 20:13:46 -0400 (AST) Received: (qmail 13442 invoked from network); 21 Feb 2006 01:14:28 +0100 Received: from unknown (HELO apollo13) (82.67.9.10) by boutiquenumerique.com with SMTP; 21 Feb 2006 01:14:28 +0100 Date: Tue, 21 Feb 2006 01:14:27 +0100 To: Marcos , pgsql-performance@postgresql.org Subject: Re: Creating a correct and real benchmark References: <1140432636.1170.6.camel@servidor> From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <1140432636.1170.6.camel@servidor> User-Agent: Opera M2/8.51 (Linux, build 1462) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.098 required=5 tests=[AWL=0.098] X-Spam-Score: 0.098 X-Spam-Level: X-Archive-Number: 200602/321 X-Sequence-Number: 17307 > I'm developing a search engine using the postgresql's databas. I've > already doing some tunnings looking increase the perform. > > Now, I'd like of do a realistic test of perfom with number X of queries > for know the performance with many queries. > > What the corret way to do this? I guess the only way to know how it will perform with your own application is to benchmark it with queries coming from your own application. You can create a test suite with a number of typical queries and use your favourite scripting language to spawn a number of threads and hammer the database. I find it interesting to measure the responsiveness of the server while torturing it, simply by measuring the time it takes to respond to a simple query and graphing it. Also you should not have N threads issue the exact same queries, because then you will hit a too small dataset. Introduce some randomness in the testing, for instance. Benchmarking from another machine makes sure the test client's CPU usage is not a part of the problem.