You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "Hall, David [IT]" <Da...@ssmb.com.au> on 2002/10/16 02:08:25 UTC

RE: Database logging and log integration idea [implementation que stion]

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:M.Kostrzewa@pentacomp.com.pl]
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Database logging and log integration idea [implementation que stion]

Posted by Michal Kostrzewa <M....@pentacomp.com.pl>.
Hi Dave,
>
> Michal, you may not have been thinking of ongoing performance monitoring of
> production systems, but this is a terrific extension for jmeter!
>
I'm very glad to hear this. JDBC logging already works (even for distributed 
jMeter testing logging to one common db :-)), I'm having some small troubles 
with viewers. Please stay tuned :-)

best regards
Michal Kostrzewa


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>