Database logging and log integration idea [implementation question]

[Michal Kostrzewa <M....@pentacomp.com.pl>]

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>

Re: Database logging and log integration idea [implementation question]

[Mike Stover <ms...@apache.org>]

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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688

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