Dynatrace Continuous Thread Analysis Feature Example

There is a new feature in Dynatrace that will allow analysis of the Java threads


To try this first the thing was to see that is produced for a single threaded program. To do this I wrote a java program that looped for ever that just calculated Pi. The code has just one thread that does the maths. I set this running and then you navigate the the process and go to “View detailed CPU breakdown” and then for the can select to ellipsis and select thread.


Before you select the threads make sure the analysis range matches the time you want to investigate. The thread analysis below is for the calculate PI, what you first see is that it is not the only main thread of the programme but you have other threads being reports. These are the threads required to run your java instance and do the garbage collection. I was a bit surprised that the overall contribution for each thread was 25% but on further reflection then if the thread is in a waiting state that Dyantrace is counting that as a valid contribution.


The next was to see what happens when I run a java program that creates a new thread from the main thread.  I called the new thread Calc Pi and this runs the Pi calculation task, while the main thread loops every second to check if the Calc Pi thread has completed. This Thread Analysis for this program is shown below:


Again the overall contribution is even across all the thread. I suspect that this will start to change when threads get into different states. The key information is the colour of the execution breakdown bar which will show that the thread is doing.

Jmeter says my browser is incompatible

A colleague was writing a script for a new application but was complaining that when he played back the script it was failing. He was seeing in the Results Tree for the page “Your browser is incompatible with this web site. Javascript must be enabled for this site to function”

This is because the default http header sent from Jmeter doesn’t support JavaScript. To get it to work he needed to copy the header from the original recording into the script.

Writing to the jmeter.log

I wanted to log some messages to the jmeter.log file during the script execution to help with debugging. The great thing with the jmeter.log file is that you can see it from both the GUI or the comand line. To write to the jmeter.log all you need to do is use< log.info("YOUR TEST") It will even write out variables as long as they are encased in ${}.

Error invoking bsh method on FileOutputStream

I have written a beanshell sampler that opens a file and outputs some variables. However, I got the following error.

Error invoking bsh method: eval Sourced file: inline evaluation of: ``f = new FileOutputStream("C:\\xxxxx.csv", true); ;'' : Object constructor

I found out that it was failing because I did not have the correct permission for directory in which the file was supposed to be written. Change the location and it worked fine!

Jmeter with Seperate Scenario file

I wanted to start running the same Jmeter test plan but for different scenario i.e. number of users etc. I had setup all the paramters in a user defined variables and changed these between run but this lead to seperate test plan files with different scenarios. The problem any change to the plan other than the variables needed to be replicated across all the test plan. There for I wanted a file that can included in the command line call when invoking Jmeter and at the same time I still wanted the ability to set the paramter via the GUI.

To do this I used the __P property function. The line below will use the pUser property if it is defined via the command line if it is not ie. from a plan invocation of the GUI it will use the value 20.


Here is an example in a dummy test plan


Next I needed to set up a properties file containing the property / value pairs. In this example I created a file peak.properties with a single line.


Then to run this from the command line I insert the -q peak.properties following to the command line.

jmeter -n -t MyTestPlan.jmx -q peak.properties

Unreadable data in the tree listener

I was recording a Siebel script in Jmeter but discovered that the data coming back was unreadable in the tree listener (see below):
compressed data

The key problem was that any Regular expressions to pull out parameters would not work. This problem was easily solved by removing the Accept-Encoding line from the Jmeter request HTTP header.

http header

Not ideal as the data will be return uncompressed so there will be more stress on the network, so something to be mindful of when looking at the Jmeter results.

Jmeter and ZLIB input stream error

Today I was trying to record a Jmeter Siebel script, and got the following error when I did the recording.

java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill…

I solved this by setting the HTTP sampler to Java

ZLIB input stream

I still have the problem that the data is encoded by that is another challange.