jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Cornelius <ph...@computer.org>
Subject RE: Jmeter becomes unresponsive
Date Wed, 11 Dec 2002 11:00:13 GMT
Because of RMI and the rmiregistry.. I had interoperability problems
between different versions of j2se.

I should perhaps have said make sure you use the same family j2se on
each of the machines.

Yours
Phil


On Mon, 2002-12-09 at 14:23, Stuart Barlow wrote:
> 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: 
> ><mailto:jmeter-user-unsubscribe@jakarta.apache.org>
> >> > For additional commands, e-mail: 
> ><mailto:jmeter-user-help@jakarta.apache.org>
> >> >
> >> > ----
> >> >
> >>
> >> > --
> >> > To unsubscribe, e-mail: 
> ><mailto:jmeter-user-unsubscribe@jakarta.apache.org>
> >> > For additional commands, e-mail: 
> ><mailto:jmeter-user-help@jakarta.apache.org>
> >>
> >>
> >> --
> >> To unsubscribe, e-mail: 
> ><mailto:jmeter-user-unsubscribe@jakarta.apache.org>
> >> For additional commands, e-mail: 
> ><mailto:jmeter-user-help@jakarta.apache.org>
> >
> >
> >--
> >To unsubscribe, e-mail: <mailto:jmeter-user-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail: 
> ><mailto:jmeter-user-help@jakarta.apache.org> 
> 
> 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:   <mailto:jmeter-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:jmeter-user-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:jmeter-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jmeter-user-help@jakarta.apache.org>


Mime
View raw message