G'day
Since you have written your own Java sampler, try this.
Instead of using a listener to write the results during the run,
accumulate
the results into memory within the sampler.
Write them out to a file at the end of the test ie when test teardown is
called. Then writing the results won't interfere with getting them.
If you only use one thread you don't need to worry about synchronisation.
If you want to use more than one thread you will either need to think
about
synchronisation of the in memory store, or have multiple separate in
memory
stores.
If you only hold the number of millisecs per sample then you should be
able
to hold a goodly number of samples in memory.
Ian Blavins
Contract Performance Engineer
Temenos
-----Original Message-----
From: Stefano Gambetta [mailto:[EMAIL PROTECTED]
Sent: 22 May 2007 15:26
To: JMeter Users List
Subject: Re: JMeter performance testing - heavy CPU utilization
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).
2) It is NOT a network problem, for the following reasons:
- 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?
4) Interesting your test with Java Request, did you use variables?
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 hope this evening I'll have the time to test.
Thanks again!
2007/5/22, sebb <[EMAIL PROTECTED]>:
>
> On 22/05/07, Stefano Gambetta <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > >
> > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
This email (and any attachments) contains confidential information, and is
intended
only for the named recipient. Distribution or copying of this email by
anyone
other than the named recipient is prohibited. If you are not the named or
intended recipient, please notify TEMENOS or the sender immediately and
permanently destroy this email (and any attachments) and all copies of it.
No
member of TEMENOS Group AG or any of its associated or affiliated
companies is
liable for any errors or omissions in the content or transmission of this
email. Any opinions contained in this email are solely those of the author
and,
unless clearly indicated otherwise in writing, are not endorsed by any
member
of TEMENOS Group AG or any of its associated and affiliated companies.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
