jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kostrzewa <>
Subject Re: File produced by the AggregateReport listener
Date Thu, 23 Jan 2003 18:33:13 GMT
Dnia czw 23. styczeń 2003 17:46, Mike Stover napisał:
> I disagree.  The point of the output is that you can load it into any of
> the listeners. If you want to see the Aggregate view of the data, load it
> into the Aggregate view. But, you still have the option of looking at the

Now my 2 cents :-) 
Of course I see your point, data collection done by listener on it's own is a 
bad idea. But I think more intuitive method will be setting this file 
*globally* for the whole tree. When you load your test results it will be 
visible in all the visualizers and you can append new results to that. And 
this hasn't to be xml file - it can be xml, csv, relational database - 
everything that will support particular, call it Logger interface. 

This interface will allow to store results and return results to visualizers. 
The problem with that is some logging backends can be very slow for some 
operation. Consider aggregate reports. For DBLogger it's simple "select .. 
group by" and executed in milliseconds, but for XMLLogger it could take ages 
and all the machine's memory ;). This is also the reason, that complicated 
repords should not be done by the visualizer which has no direct acces to 
data source (e.g. JDBC connection object). At least I'm trying to implement 
that :-)

Moreover I thought about another feature - every Sampler and Controller (not 
visualizer) will have flag "log request" so you can switch particular 
requests or groups of requests to exclude not interesting requests and to 
save the disk space.

Another feature can be "test results desktop" and "test results metadata" - 
with that you can describe/view/erase your test results. I've encoured this 
problem in jdbc logging, when I can't just log test to named file - there has 
to be some key to distinguish tests (in jdbc logging it's implemented as 
test_id field). It will also helps to keep test results in order.

What do you think about it?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message