On 23 Jan 2003 at 21:28, Michal Kostrzewa wrote: > > > > 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. > > It'll be good solved by configuration of sampler/controller.
Not exactly. Yes, the ideas below would allow config of what data gets saved in each sample result, but what I'm talking about is the ability to organize which requests a listener "hears from". It's not quite the same thing. > > > > 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. > > I've agreed that from the beginning, sorry if I haven't state it clearly. > The main problem is that visualizer can't have reporting logic, which can > sound strange, but without access to raw data source visualizer can't take > advance of db aggregation. On the other side we can give such access to the > visualizers, but then they won't be independent from logging logic. I still > have conception problems with that. Ok, now I'm with you. I agree - but I'd like to enhance our save format to allow multiple test runs to exist in one file and/or allow listeners to load data from multiple sources and combine them in a reasonable way. I don't think this would be too hard - there just needs to be some information about the test run included (time of start, time of end, for example). And then listeners could use that information to appropriately combine data from multiple test runs. Not all listeners, of course - graph listener would benefit little from this, but it's fine to leave it up to the individual listener component to implement this or not. The important thing is to make the info available in the data. > > >> > > Sounds great. I would vote for just eliminating the XML format and going > > to CSV (for files). > > Some people *love* XML, fluently uses tools for evaluating reports, and got > used to it, it should stay. Fast visualizers are not necessary for these > people. Yes, I suppose you're right. > [snip] > > Well - imagine such situation. You have an application to test, and you want > to draw plot describing application response time (on Y axis) v.s. the count > of users (on X axis), to determine scalability of the application. So you > have to make several stress tests with increasing thread number. You want to > log results to the database. Probably you want to create only *one* db and > that DB has table storing test results. However you want to make SQL queries > selecting only choosen test (for the n-th user) - you have to have some way > to assign sample result in the table to given test. This is no big deal when > saving to files - you just name that files appropriately 1-user.jmx, > 10-users.jmx ... 100-users.jmx. > Extension to that idea is to make fields to describe the test - who, when, > subject of test, description and so on, to provide some orgranization. Again, > when using files it's simple - you could name file like > test_done_2000_10_10_by_MKO_10_users_failed_because_of_application_errors.jmx > but it's not standarized, not elegant and impossible for DB's. Sounds good so long as we understand there's no real difference between a database and a file system - from the listener's point of view. In other words, all this should be possible whether you're using a database or just files. Granted, files may be slower and less efficient, but it should still work either way. Also, this goes back to what I said earlier about saving information about each test run so that listeners can appropriately combine results from multiple test runs. That's what you are describing here, if I understand rightly. -Mike > > How with that? > best regards > Michal Kostrzewa > > > > -- > 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]>
