Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of woolfel@gmail.com designates
 64.233.162.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Cog03eLouYn7aQVb6R5rA/WHLLgWMwvqm8rZwFKMGxkk3Db0YWYSG6gKbITW5KgOzoPEguPooXoKAA8QTdQ+wicCqowlNOuVPVJJ9I6kzqSwd1cH4S9LFXiusfzL5xCE1QpSV56Gy3k/TJ43kkKQ6SW86LjEhSxuBaxqOqe6RTM=
Message-ID: <27e674a90511272204u6c023113v3ef441be10d36405@mail.gmail.com>
Date: Mon, 28 Nov 2005 01:04:52 -0500
From: Peter Lin <woolfel@gmail.com>
To: JMeter Users List <jmeter-user@jakarta.apache.org>
Subject: Re: Interpreting results
In-Reply-To: <20051128040301.79988.qmail@web35814.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_54304_23421185.1133157892863"
References: <27e674a90511270855k66cdb05co3608f337db6ab2f2@mail.gmail.com>
	 <20051128040301.79988.qmail@web35814.mail.mud.yahoo.com>

------=_Part_54304_23421185.1133157892863
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

sounds like a tricky situation.  a couple of things come to mind.  the most
useful one is to take production logs and use those to run the tests.

what I would do to isolate the database issues is to use the same test plan=
,
and vary the sql and concurrent load.

In other words.

Test plan + old sql
test plan + optimized sql

run both combinations above with different concurrent load. You'll have to
run it for a large sample to get a good estimate. A small sample will likel=
y
be mis-leading. I consider a large sample something over 500K. hope that
helps

peter


On 11/27/05, m mat <perftest99@yahoo.com> wrote:
>
> Performance experts,
>
>   I am testing a web services server that relies on a SQL server DB as
> system of records. The way this data base is ,  most of the search web
> services, make the DB CPU utilization go petty high momentarily (close to
> 50% or so) on a single (standalone) query operation
>
>   Under load - as I can not predict what operation will run concurrently
> with what other operation - I have a huge variance in the execution of th=
ese
> search operations (any where from the its base time to about 10 times the
> base time). Average of such a number also does not make much sense. As a
> result, as I try to optimize the DB or other layers, I can not confidentl=
y
> say that performance is improving or not, as every time I run it, I get
> different numbers for each search operation depending on what else is
> running concurrently with it.
>
>   Of course I can run these search operations one at a time (i.e. not run
> any thing else when a search is running - in a single thread), but then I
> can not see some other issues that I need to observe.
>
>   How do you tackle such a situation?
>
>   Matt
>
>
> ---------------------------------
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
>

------=_Part_54304_23421185.1133157892863--