Member Avatar for gunbuster363

I have searched on the internet before, but cannot get a suitable tool.
I found tools to profile jdbc performance, gc statistics, but no some obvious tool to measure the time spent in each statement.

I would like found which statements are spending the most of the time of my app in my company. However, I cannot install anything on the server of my company, can I still measure the time?

Usually we develop the program in eclipse first, then we move the progame to the linux server. I can install app for eclipse. Or if JVM provide someway to do this profiling, I would be pleased and thankful to know about that.

Thank you all.

  • 2 Contributors
  • 2 Replies
  • 102 Views
  • 14 Hours Discussion Span
  • Latest Post Latest Post by gunbuster363

Dani AI

Generated

— the key constraint is whether you can change the running JVM or only change the app you deploy. Below are practical approaches depending on what you are allowed to do.

If you cannot add anything to the server or change JVM startup

  • Add lightweight timing/metrics directly in the code and redeploy. Measure with System.nanoTime() or use a metrics library (Micrometer / Dropwizard Metrics) to record timers and percentiles, then log or export them. This is safe and low-risk for production.
  • Use compile-time AspectJ or simple utility wrappers so you don’t scatter timing code through business logic.

Quick timing snippet you can drop around suspect blocks:

long t0 = System.nanoTime();
try {
    doWork();
} finally {
    long ms = (System.nanoTime() - t0) / 1_000_000;
    System.out.println("doWork took " + ms + " ms");
}

If you can run commands on the server (but not install new software)

  • Check whether the JVM supports Java Flight Recorder (JFR). Modern OpenJDK builds include JFR (see JEP 328: https://openjdk.org/jeps/328). If JFR is available you can trigger short, low-overhead recordings with jcmd and then analyze the .jfr file in Java Mission Control (JMC: ). Run jcmd <pid> help JFR to see supported subcommands on that JVM.

If you can reproduce the workload locally or on a staging machine

  • Run a profiler in your dev environment (VisualVM is shipped/available: https://visualvm.github.io/) or use a more advanced sampler on a copy of production data. This avoids touching production and gives good CPU/hotspot visibility.

Notes and tradeoffs

  • Sampling profilers (JFR, VisualVM sampling, async-profiler) give low-overhead hotspots; instrumentation gives exact timings but higher overhead. Wall-clock (I/O) waits vs CPU time differ — pick the tool accordingly.
  • If you try the suggestion from about using a profiler, confirm whether that profiler is bundled with your JVM or must be added separately; different profilers have different install/attach requirements.

The fastest path is: reproduce the issue locally and profile, or add targeted timers in the code if you must change only the application.

Recommended Answers

All 2 Replies

Member Avatar for ~s.o.s~

By statements do you mean "code"? If yes, then JProfiler which is included with JDK 6 can be used for CPU profiling and at the end of the run gives the total time taken by each method till now. Search around for CPU profiling JProfiler.

Member Avatar for gunbuster363

Thanks, try it later!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.