jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JMeter performance testing - heavy CPU utilization
Date Tue, 22 May 2007 14:38:32 GMT
On 22/05/07, Stefano Gambetta <stedata@gmail.com> wrote:
> Seb, thanks for the reply.
>
> 1) About 1000 q/s is what I get with JMeter, while with queryperf I can
> saturate the server throughput at about 8000 q/s (with 30% cpu on the
> sampler host).

Still pretty good performance from a single thread...

How many threads does queryperf use, or is it singlethreaded?

> 2) It is NOT a network problem, for the following reasons:

I did not say it was a network problem.

I meant that the major contribution to the sample time was likely to
be the network.

> - bandwith is very far from saturation
> - with queryperf I can reach 8x throughput (and still far from network
> saturation)
>
> I've tried adding more theads (up to 3), the throughput increases up to a
> point (about 1500-1700 qps) but not further, due to the fact the CPU is
> already satuarted.
>

> 3) Variables: Yes in the java request I use two of them (name_server and
> host_to_be_resolved). Than can be a source of CPU processing on the sampler?

It will definitely require more CPU as there is more to do, but I need
to check if it is a significant increase or not.

> 4) Interesting your test with Java Request, did you use variables?

No; but I will try that.

> 5) SUN JDKSE 6 (debian package)
>
> 6) Actually I already use sampleStart() and sampleEnd(), sorry I didn't
> remember that
>
> 7) Interesting test plan, why do you think it would be better?

I don't think the plan would be better.

The idea was to see if you got similar results to mine when using the
Java Request / JavaTest sampler provided with JMeter.

Your host seems similar to mine in CPU power, but the OS is different.

> I hope this evening I'll have the time to test.
>
> Thanks again!
>
> 2007/5/22, sebb <sebbaz@gmail.com>:
> >
> > On 22/05/07, Stefano Gambetta <stedata@gmail.com> wrote:
> > > Hello,
> > >            first of all thanks for the prompt replies!
> > >
> > > I'll try to answer to all the asked questions.
> > >
> > > Seb:
> > >
> > > 1) I get a max throughput of about 1000 queries sent / sec. I measured
> > > throughput counting the result file number of lines.
> > > I also measured that with sar, more or less they are the same.
> >
> > Is this with JMeter or the C program?
> >
> > If JMeter, then I don't think you have a problem.
> >
> > If not JMeter, then what throughput did you get with JMeter?
> >
> > > 2) query response time is very small, in the interval [0,2] ms. The load
> > > test scenario regards an authoritative DNS server, that means that all
> > the
> > > queries are answered from its cache. This is by design. The same query
> > is
> > > sent in every test.
> >
> > So the main delays will probably be due to network speed.
> >
> > > 3) what do you mean by functions or variables? The run method of my test
> >
> > I mean ${variable) or ${__function()} references in the test plan.
> >
> > > class is a simple:
> > >
> > > start_time = System.currentTimeMillis();
> > > lookup.run() // send the query
> > > stop_time = System.currentTimeMillis();
> > > results.setTime(stop_time - start_time);
> >
> > You should really use
> >
> > results.sampleStart()
> > lookup.run() // send the query
> > results.sampleEnd()
> >
> > Otherwise the result is not set up properly.
> >
> > > 4) Java 6, Linux 2.6.18, Jmeter 2.2
> >
> > Which supplier of Java?
> > Some versions of Java seem to be very inefficient compared with Sun
> > Java on Windows.
> >
> > > Ian:
> > >
> > > 1) I'm using only one thread, since it is enough to saturate the sampler
> > > CPU. This machine is a single CPU (AMD 1600+ XP).
> > >
> > > 2) There is NO think time (neither in queryperf nor in my jmeter
> > sampler),
> > > by design. I'm modelling the sistem as an open queueing center with a
> > > transactional load.
> > >
> > > Seb:
> > >
> > > 1) What kind of test did you performed? Sistems, CPUs, DNS servers,
> > threads?
> >
> > Windows XP, Sun Java 1.4.2_13, Pentium 1.6GHz 1GB RAM.
> >
> > No DNS servers, 1 thread
> >
> > > How, in java, did you performed the name resolution? Are you sure you
> > are
> > > not measuring your resolver performance, instead of the server one?
> > > I have used the dnsjava package just for this purpose, since it sends
> > each
> > > query directly to the DNS server usign sockets, instead of using system
> > > resolver libs, which cache the replies.
> >
> > I did not use DNS; I just used Java Request.
> >
> > > 2) The slowdown writing result file is interesting, I will try using the
> > > summary listener!
> >
> > > I'm interested to hear how you reached such a high throughput!
> >
> > > Thanka again, if you have other questions just let me know :)
> >
> > I suggest you try the following test on your host:
> >
> > Thread Group 1 thread, 1 loop
> > + Loop Controller 1000
> > + + Java Request time=0 mask=0 (name = Java0)
> > + Loop Controller 1000
> > + + Java Request time=10 mask=0 (name = Java10)
> > + Summary Report
> >
> > and report the results.
> >
> > [I can e-mail the plan to you privately if you want]
> >
> > > 2007/5/22, sebb <sebbaz@gmail.com>:
> > > >
> > > > I've just done a test using the Java Request / Java Test sampler in
> > JMeter
> > > > 2.2.
> > > >
> > > > If I set the sleep_time and sleep_mask to 0, I can get a throughput of
> > > > 20,000-30,000 per second. Obviously this uses around 100% CPU.
> > > >
> > > > For sleep_time of 10, I get an average elapsed of 15ms, and throughput
> > > > of 64/sec which equates to 15.625ms per sample. The average figure of
> > > > 15ms is rounded down, so this agrees with there being very little
> > > > overhead. CPU usage is minimal.
> > > >
> > > > Note that I was using only the Summary Report listener.
> > > >
> > > > If the output is written to a file, then the throughput for the 0
> > > > sleep drops to 3,500-7,000/sec. However the rate for the 10ms sleep
> > > > samplers is only marginally affected, e.g. 63.9 for CVS and 63.8 for
> > > > XML with 1000 samples.
> > > >
> > > > The above suggests that JMeter is behaving well for the limited tests
> > > > I performed.
> > > >
> > > > S
> > > > On 22/05/07, sebb <sebbaz@gmail.com> wrote:
> > > > > There could perhaps be a problem...
> > > > >
> > > > > What throughput did you get?
> > > > > What was the average sampler response time?
> > > > > Are you using any functions or variables?
> > > > > Which version of Java, and which OS?
> > > > >
> > > > > S.
> > > > > On 22/05/07, Stefano Gambetta <stedata@gmail.com> wrote:
> > > > > > Hello,
> > > > > >   I'm evaluating JMeter as a load testing framework for my
> > performance
> > > > > > analysis.
> > > > > >
> > > > > > I'm going to load test a DNS server. To do so, I've written
my own
> > > > Java
> > > > > > Request sampler, which issues DNS requests using the package
> > dnsjava.
> > > > > >
> > > > > > My test configuration is very simple: one thread-group (one
therad
> > > > > > configured for example), one java request sampler, one simple
data
> > > > writer as
> > > > > > listener.
> > > > > >
> > > > > > The problem basically is that with that configuration JMeter
can
> > reach
> > > > a
> > > > > > very low throughput (query sent / sec), since during tests CPU
get
> > > > > > saturated.
> > > > > >
> > > > > > The known bind queryperf tool can generate a load about six
times
> > > > higher
> > > > > > while using less than 30 % CPU. Since this tool is a simple
C
> > program,
> > > > I
> > > > > > expected a greater performance, but that results seems to be
> > > > exaggerated.
> > > > > >
> > > > > > I assumed that my sampler class was not well optimized, so I
did a
> > > > quick
> > > > > > profiling of JMeter, during the test, in order to discover some
> > areas
> > > > of
> > > > > > improvement.
> > > > > >
> > > > > > I think I saw an interesting result: most of the thread sampler
> > time
> > > > is
> > > > > > spent in one method of one particular class of JMeter, and a
minor
> > > > part is
> > > > > > spent inside the Java Request sampler. The mentioned method
is:
> > > > > >
> > > > > > SamplePackage.setRunningVersion()
> > > > > >
> > > > > >
> > > > > > Giving that results, I have some questions:
> > > > > >
> > > > > > - what does that method do?
> > > > > > - is it possible to reduce its overhead?
> > > > > >
> > > > > > Thanks for any replies
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>

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


Mime
View raw message