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.
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.
3) what do you mean by functions or variables? The run method of my test
class is a simple:
start_time = System.currentTimeMillis();
lookup.run() // send the query
stop_time = System.currentTimeMillis();
results.setTime(stop_time - start_time);
4) Java 6, Linux 2.6.18, Jmeter 2.2
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?
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.
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 :)
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]
