4

I am having a java application which makes a lot of external http calls. To identify the hot methods I have used System.currentTimeMillis() in all methods and I observed that the methods who are actually making the external HTTP calls are the hot methods, which is quite expected.

But when I profiled the app using Java Mission Control(JMC) the Hot Methods under Code tab list is entirely different. In fact almost none of the methods making the external HTTP calls came up in the JMC list.

Can some one please let me know:-

  1. Are the Hot Methods(under Code section) is based on CPU Time or Wall-Clock Time?
  2. Is there a way I can view the list of methods which actually are taking more Wall-Clock time?
  3. If JMC does not support showing the list of Hot Methods is there any other tools which show this?
Kire Haglin
  • 6,569
  • 22
  • 27
tuk
  • 5,941
  • 14
  • 79
  • 162
  • 1
    It's really hard to tell from the JMC and JFR doc if you can make it sample on wall-clock time, not CPU time. If you only sample on CPU time, it will not show you time spent in I/O. – Mike Dunlavey Jul 10 '16 at 20:29
  • Is there some other tool which will allow me to do so for Java apps? What is the best way then to identify the hot methods based on clock time? Is it the way I am doing now by using `System.currentTimeMillis()` at the entry and exit of a function? – tuk Jul 11 '16 at 07:58
  • 1
    The method many people rely on is not done with measuring time. It is done with random-time capture of 10-20 stack samples, such as by using the *jstack* utility. You can tell a great deal from those. You want to know which methods are "hot"? They are the ones that are on the stack a high fraction of time. Example: if method A is responsible for 40% of wall-clock time, then each sample has a 40% chance of seeing it, so it will appear on 40% of samples, more or less. This works whether A is big and invoked just once, or small and invoked a million times. – Mike Dunlavey Jul 11 '16 at 13:15

1 Answers1

0

  1. The histogram is based on CPU time from threads that are executing Java code.

  2. No, but there is a view where you can see where latencies are, caused by lock contention, socket and file I/O, but it will not give the aggregated time, only outliers.

JDK 10 has a new event that samples methods that are in native, regardless if the method is running code or waiting. it may show methods that are waiting on I/O There are however no visualization of those events in JMC.

Kire Haglin
  • 6,569
  • 22
  • 27