On 23 Jan 2003 at 19:33, Michal Kostrzewa wrote: > 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.
Except the current implementation allows a user to set up multiple listeners that listen to specific requests. The listeners work hierarchically too - if you add a listener to a specific controller, it will only log samples from requests under that controller. If you went to a global file, you'd lose that capability - which I think is useful. I don't really understand why the logged files should be different from listener to listener. Surely XML is slow and bad and we all agree on that, and we'd all like it configurable as to what information is logged, but I strongly object to anything being put in those files that is calculated by a specific listener. And that is what is being asked for, essentially. > > 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 :-) Sounds great. I would vote for just eliminating the XML format and going to CSV (for files). > > 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. Cool. While we're there - why not a full config option for each request to indicate what should be saved and what should be tossed? It could be a simple button that opens up a dialog screen to configure the report for that request or controller. Or, it could be a new kind of test element - Log Config. > > 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. I didn't understand this. -Mike > > What do you think about it? > Michal > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
