Return-Path: Delivered-To: apmail-jakarta-jmeter-user-archive@apache.org Received: (qmail 44245 invoked from network); 9 Dec 2002 14:23:48 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 9 Dec 2002 14:23:48 -0000 Received: (qmail 29665 invoked by uid 97); 9 Dec 2002 14:24:51 -0000 Delivered-To: qmlist-jakarta-archive-jmeter-user@jakarta.apache.org Received: (qmail 29644 invoked by uid 97); 9 Dec 2002 14:24:51 -0000 Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "JMeter Users List" Reply-To: "JMeter Users List" Delivered-To: mailing list jmeter-user@jakarta.apache.org Received: (qmail 29632 invoked by uid 98); 9 Dec 2002 14:24:50 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-Id: <5.2.0.9.0.20021209142318.02822bc0@10.136.31.17> X-Sender: sbarlow@10.136.31.17 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Dec 2002 14:23:40 +0000 To: JMeter Users List From: Stuart Barlow Subject: RE: Jmeter becomes unresponsive In-Reply-To: <147054F9261B8E0080256C71004F247C.004F24DD80256C71@peopledo c.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Why do you say move to 1.4? At 14:24 14/11/02 +0000, Phil Cornelius wrote: >Yes.. >Make sure you run the jmeter gui on yet another separate machine purely >for collecting together the data. > >Another tip is to use j2se 1.4.x on each machine. > >Yours >Phil > > >On Thu, 2002-11-14 at 14:02, Vola, Guillaume wrote: >> Tx for the answer. >> In my understanding you run each different thread group >> on a different machine on which you have started a jmeter-server. >> The list of the machine that simulates a client is contained >> in a properties file (remote_hosts). >> The number of threads depends on the CPU of the client machine. >> Is it correct ? >> >> >> My JMeter client is running on Solaris: >> Sun Enterprise 220R (2 X UltraSPARC-II 450MHz) >> >> B.T.W. On Windows I get the following traces: >> >> DEBUG 10372 [jmeter.g] (): Start : GraphAccumModel1 >> DEBUG 10372 [jmeter.g] (): End : GraphAccumModel1 >> DEBUG 10372 [jmeter.g] (): Start : init1 >> DEBUG 10372 [jmeter.g] (): Start : GraphAnnum1 >> DEBUG 10372 [jmeter.g] (): End : GraphAnnum1 >> DEBUG 10372 [jmeter.g] (): Start : GraphAnnum2 >> DEBUG 10372 [jmeter.g] (): Start : setModel1 >> DEBUG 10372 [jmeter.g] (): End : setModel1 >> DEBUG 10372 [jmeter.g] (): End : GraphAnnum2 >> DEBUG 10372 [jmeter.g] (): toString1 : Returning - Show the samples >analysys as dot plots >> DEBUG 10372 [jmeter.g] (): setVisualizer1 : Setting visualizer - Show >the samples analysys as dot plots >> DEBUG 10372 [jmeter.g] (): End : init1 >> DEBUG 10372 [jmeter.g] (): Start : GraphAccumVisualizer1 >> DEBUG 10372 [jmeter.g] (): End : GraphAccumVisualizer1 >> DEBUG 10372 [jmeter.g] (): Start : ViewResultsFullVisualizer1 >> DEBUG 10372 [jmeter.g] (): End : ViewResultsFullVisualizer1 >> >> -----Original Message----- >> From: Phil Cornelius [mailto:philc@computer.org] >> Sent: Thursday, November 14, 2002 10:59 AM >> To: JMeter Users List >> Subject: Re: Jmeter becomes unresponsive >> >> >> I was getting this problem.. and various other performance problems i.e. >> results trickling back.. >> >> It is simply because the client machine is maxed out on CPU.. I have >> since distributed my test across a number of machines with great >> success.. >> >> http://jakarta.apache.org/jmeter/usermanual/remote-test.html >> >> In my situation I can run about 300 threads on each client machine >> (cheap Celeron 1300s).. >> >> If you are windows you can use perfmon to see how the cpu is doing on >> each machine and adjust your load. >> >> Yours >> Phil >> >> >> On Thu, 2002-11-14 at 09:09, Vola, Guillaume wrote: >> > Hi there, >> > >> > During my perf tests I encountered some issues with JMeter >(V1.8/jdk1.4). >> > As Listener I have only one Agregate Report with NO output file. >> > Sometimes during long time test JMeter becomes unresponsive (grey >screen). >> > That happended after a while with the following scenario: >> > #threads=360 >> > Ramp-up=3600 >> > Loop=10 >> > Jmeter should have launched 3600 requests to my server but it has been >stopped after ~2000. >> > No OutOfMemory in the Jmeter console !!! (JMeter launched with the >option -Xmx512m) >> > >> > Is someone has an idea to resolve this issue I would really appreciate >it. >> > I attached my test plan to this message. >> > Best regards. >> > Guillaume >> > >> > -----Original Message----- >> > From: Mike Stover [mailto:mstover1@apache.org] >> > Sent: Wednesday, October 16, 2002 7:02 PM >> > To: JMeter Users List >> > Subject: RE: OutOfMemoryError during test perf >> > >> > >> > On 16 Oct 2002 at 17:03, Vola, Guillaume wrote: >> > >> > > Michal, >> > > >> > > Thanks for your answer. I start to see clearer >> > > but I still have some questions. >> > > >> > > > Should I use non-GUI mode for high load testing ? >> > > Hmmm... is there a possibility to use non-GUI mode for remoted >testing? I was >> > > always using it that way: several servers (jmeter -s) of course >without gui >> > > and one control console with GUI where you can order servers to >run... How >> > > can you run test on servers without GUI? >> > > When not using remote testing I always use non-GUI mode for load >testing. >> > >> > JMeter can't currently control remoted JMeter instances in non-GUI >mode. >> > >> > > >> > > Q1: I use remote testing because my server is hosted by a different >machine >> > > than my desktop. I think I will schedule a non-GUI test for that >night. >> > > In this case how do you analyze/visualize the sample results file >[.jtl] ? >> > >> > You can open results files in any visualizer. The visualizer will show >the data in its >> > own way. >> > >> > > >> > > Q2: When you have a scenario with cascaded HTTP request, >> > > how do you measure the response time for the whole scenario, >> > > and not only for every sample. In my understanding one HTTP request >> > > corresponds to one sample (the average time is calculated >> > > for all samples). >> > >> > There is no "transaction timer", but you could use the Aggregate >Visualizer which >> > would give you average and throughput times for each sample, from which >you >> > could easily add three together to find the average transaction time >for those three. >> > Same with throughput. >> > >> > -Mike >> > >> > > >> > > Best regards, >> > > -Gui >> > > >> > >> > >> > >> > -- >> > Michael Stover >> > mstover1@apache.org >> > Yahoo IM: mstover_ya >> > ICQ: 152975688 >> > >> > -- >> > To unsubscribe, e-mail: > >> > For additional commands, e-mail: > >> > >> > ---- >> > >> >> > -- >> > To unsubscribe, e-mail: > >> > For additional commands, e-mail: > >> >> >> -- >> To unsubscribe, e-mail: > >> For additional commands, e-mail: > > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: > Stuart Barlow Tel: +44 131 468 8205 ************************************************************************* Information in this email is confidential and may be privileged. It is intended for the named addressee(s) only. If you have received it in error please notify the sender immediately and delete it from your system. You should not otherwise copy, retransmit, use or disclose its contents to anyone. ************************************************************************* -- To unsubscribe, e-mail: For additional commands, e-mail: