This is brilliant. First, I really like JMeter and want to thank the developers whole heartedly for saving me big $'s and time and reading my mind with enhancement ideas.
I have a system which restricts each user to a single login (lunatics running the asymlum syndrone)... Anyway, 1.7 I had 23 thread groups to login as 23 different users - a bit unwieldy. I also needed to report total throughput - but there were not timestamps in the file reporter output so no way to get this acurate. I thought I would download the source and get to work. So, got the source from cvs, thought before starting to code, why not build it and see if anything had changed much since last "release" And Wow! 1.7.3 is magic. 1.7.3 - one thread group and 23 user variables. Beautiful! Throughput right on the Graph Results! File Logging on every Listener rather than Separate - and much richer output. Needless to say, I am much more comfortable with the testing results and can present better analysis. Now that the system goes live, how does one record performance sampled periodically for monitoring and analysis of trends, degredation, alarms, etc.... A key functionality to achieve this would be to log to a database..... Need I say more ? Michal, you may not have been thinking of ongoing performance monitoring of production systems, but this is a terrific extension for jmeter! Regards, Dave David Hall Senior Domain Architect Citigroup Australia/NZ -----Original Message----- From: Michal Kostrzewa [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 8:28 AM To: JMeter Users List Subject: Database logging and log integration idea [implementation question] Hi all, I have some questions about extending jMeter and I'm placing it on users list, because somobody may be interested in it. My ideas (problems and solutions) The problem number 1: When you do a long test with jMeter even not logging everything you receive *very* long XML log file (tens of MB and more) which cannot be processed with standard jMeters browsers, because they try to load all the file to memory. This reason also causes problems when running tests with GUI and listeners - after some time you receive OutOfMemory exceptions. Proposed solution: I implemented JDBCLogging, - now you can store samples to database. You can test in GUI mode and you can browse and analyze files *very* efficiently, because only records seen on the screen are fetched from the (indexed) database. Easy management of tests and ability to ask complicated SQL questions allows doing functional tests when using long and heavy load. Such tests can reveal uncommon application errors not happening when one tester is doing so called functional test (e.g. deadlocks and such) The problem number 2: Today, web applications have multi tier architecture. So we have browser - www server (e.g. Apache) - frontend (e.g Tomcat) - backend (e.g. some EJB containger) - database (e.g. ORACLE). When testing you replace browser with jMeter and you get 5 different log files possibly on 5 different machines. It's uneasy to answer the question e.g. "What user have exactly seen (HTML Content), when we get on EJB container such nasty SQLEXception" or say something about cicrumstances (requests) causing this error. Proposed solution: I'm implementing an extension to problem 1, in which every server log is collected in one database. It can be done on 2 ways: "online logging" - for example you can set log4j.properties, so the application can log into your (jMeters) database and "offline logging" when you just import logs to database after tests. All logs have similar structure: "timestamp" and "content" and possible (and very useful) "sessionid" which can be used to distinguish users and trace them in all layers. In jMeters viewers there will be table with all logs sorted by timestamps and filtered by sessionid so you can easily trace flow of control in all the layers. When I'm finish, I'll of course send it to jMeters developers if they like it. But here goes developement question: I've already implemented JDBC logging and it works, but I'm not sure I did it in proper way: I implemented DBResultCollector as a SampleListener and TestListener, and you can place it into the tree. You can configure the test and logging option here (fine grained). Then you add to this element visualizers (only implemented DBTableVisualizer already). This visualizers implements DBViewer interface and DBResultCollector takes care of DBViewers notification. I've only modified MenuFactory to provide standard menu for DBResultCollector. Is my approach sensible? For some strange reason it's not working when I place it in the Test node instead of ThreadGroup. Also I had to implement another TableViewer, but the better (but unfeasible) solution was subclass standard TableViewer and change only tablemodel there. In my solution you configure JDBC and logging in DBResultCollector not using any ConfigTestElements. I'll really appreciate any comments on this and I can redesign it if it will be neccessary. best regards Michal Kostrzewa -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
