Java measure short thread runtime runtime

Question

I am currently working on some kind of basic database software. Basically, I am trying to simulate the use of threads by a certain number of clients that all repeat the same operation (for example: a read operation) against a database for a certain period of time.
During this time, I want to measure the average delay in each thread to get a response from the database.

My first choice was to rely on the ThreadMXBean getThreadCpuTime () method ( http://docs.oracle.com/javase/7/docs/api/java/lang/management/ThreadMXBean.html ), but the thing is that the operation is too fast (getThreadCpuTime () before the operation is equal to getThreadCpuTime () after the operation).

I did a little experiment to understand and illustrate the problem:

public class ExampleClass { class LongRunningThread extends Thread { private int n; public LongRunningThread(int n) { this.n = n; } public void run() { ArrayList l = new ArrayList(); for (int i = 0; i < n; i++) { l.add(new Object()); } long time = ManagementFactory.getThreadMXBean().getThreadCpuTime(this.getId()); System.out.println("Long running thread " + this.getId() + " execution time: " + time); } } class MyThread extends Thread { int n; public MyThread(int n) { this.n = n; } public void run() { ArrayList l = new ArrayList(); for (int i = 0; i < n; i++) { l.add(new Object()); } long time = ManagementFactory.getThreadMXBean().getThreadCpuTime(this.getId()); System.out.println("My thread " + this.getId() + " execution time: " + time); } } public static void main(String [] args) { System.out.println("Cpu time supported? " + ManagementFactory.getThreadMXBean().isThreadCpuTimeSupported()); System.out.println("Cpu time enabled? " + ManagementFactory.getThreadMXBean().isThreadCpuTimeEnabled()); for (int i = 1; i < 10; ++i) { new LongRunningThread(i*1000000).start(); } for (int i = 1; i < 10; ++i) { new MyThread(i*100).start(); } } Output: Cpu time supported? true Cpu time enabled? true My thread 18 execution time: 0 My thread 26 execution time: 0 My thread 20 execution time: 0 My thread 22 execution time: 0 My thread 24 execution time: 0 My thread 21 execution time: 0 My thread 25 execution time: 0 My thread 19 execution time: 0 My thread 23 execution time: 0 Long running thread 9 execution time: 15600100 Long running thread 10 execution time: 15600100 Long running thread 11 execution time: 46800300 Long running thread 12 execution time: 31200200 Long running thread 14 execution time: 78000500 Long running thread 13 execution time: 78000500 Long running thread 17 execution time: 124800800 Long running thread 15 execution time: 140400900 Long running thread 16 execution time: 109200700 

I cannot get runtime for all MyThread instances, but no problem for LongRunningThread instances. As I said, my hypothesis is that the operation performed using the first threads is too fast to be actually measured. Is there a way to achieve what I'm trying to do? Can runtime be measured for such short time streams?

Thanks in advance for your help:)

Answer 1

You have reviewed this structure http://metrics.codahale.com/ . It is very good and comes with built-in support for exposing metrics via JMX

Answer 2

as a simpler solution, which you can use as follows:

 class MyThread extends Thread { int n; public MyThread(int n) { this.n = n; } public void run() { long startTime = System.nanoTime(); ArrayList l = new ArrayList(n); for (int i = 0; i < n; i++) { l.add(new Object()); } long time = System.nanoTime() - startTime; System.out.println("My thread " + this.getId() + " execution time: " + time + " ns"); } } 

if you don't need nanosecond accuracy, you can use System.currentTimeMillis() instead.

Answer 3

Can runtime be measured for such short time streams?

Without measuring the wall clock time using a nano-second clock, the answer may be negative. For small cycles, the measured CPU time may be less than the accuracy of the method. javadocs for ThreadMXBean.getThreadCpuTime(...) say:

Returns the total processor time for the stream of the specified identifier in nanoseconds. The return value is nanosecond precision, but not necessarily nanosecond precision.

One thing to consider is to take the processor time if it is> 0, and take the wall clock time if it is 0.