Logging to a database is an excellent idea, though you'll want to abstract the code enough that it can log to any SQL-compliant database.
It should be possible to enable all the current visualizers to use the database logging. Currently, all visualizers allow one to choose a file to log to (or load data from). It would be a fairly simple matter to give a choice of a file or a database, and make the visualizer behave accordingly. Also, the current method of saving log information via xml is looking like a failed experiment. The idea was to have a format easy to parse for external uses, but it's too much inefficiency for dubious gain. I will probably look at changing the format to a less self-explanatory, but more efficient format, like csv. -Mike On 16 Oct 2002 at 0:28, Michal Kostrzewa wrote: > 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]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
