INTRODUCTION jHiccup is an open source tool designed to measure the pausesand stalls (or “hiccups”) associated with an application’s underlyingJava runtime platform. The new tool captures the aggregateeffects of the Java Virtual Machine (JVM), operating system,hypervisor (if used) and hardware on application stalls andresponse time. jHiccup allows developers, systems operators and performanceengineers to easily create and analyze response time profiles, andto clearly identify whether causes of application delays reside inthe application code or in the underlying runtime platform. jHiccupis completely transparent and non-intrusive to the application, haszero performance overhead in operation, and is compatible with allJava applications using any JVM.
MEASUREMENTS The hiccups measured are NOT stalls caused by the applicationscode. They are stalls caused by the platform that would be visibleto and affect any application thread running on the platform at thetime of the stall. jHiccup shows graphically via Hiccup Charts justhow responsive the runtime platform really is. By understandingthe pauses associated with the underlying platform, ITorganizations can better isolate latency and delays and thecontributing components. If jHiccup experiences and records a certain level of measuredplatform hiccups, it is safe to assume that the application runningon the same JVM platform during that time had experiencedhiccup/stall effects that are at least as large as the measuredlevel.
FUNCTIONALITIES jHiccup helps you avoid common pitfalls in applicationperformance characterization. Most performance reportingassumes a normal distribution of response times (single mode),yet most real systems are multi-modal due to GC pauses, OS orvirtualization hiccups, swapping, etc. jHiccup can help you findand identify the causes of these delays that affect response times. jHiccup works with any Java application. It is non-intrusive, runson all major operating systems and is compatible with all JVMs. jHiccup is run as a wrapper around other applications so thatmeasurements can be done without any changes to applicationcode. Other tools focus on the application itself; jHiccup is unique inlooking at the underlying platform.
HOW TO RUN JHICCUP To use jHiccup, include the script command in your Java application startcommand.For example:If your program were normally executed as:java <Java args> UsefulProgram -a -b –cThen the launch line would become:jHiccup java <Java args> UsefulProgram -a -b -c.
JHICCUP LOG FILES jHiccup records hiccup durations observed by the application itwraps. It produces two log files that are updated at each recordinginterval (which defaults to 5 seconds). The two log files are: hiccup.<identifier>.log:A single line entry is appended to the log file at everyrecording interval. Each entry line lists the hiccup duration ofcertain percentiles (50%, 90%, Max) of samples collected in the pasta aecording interval, as well as aggregate percentiles (50%,90%, 99%, 99.9%, 99.99%, Max) for samples accumulated sincethe beginning of the jHiccup run. hiccup.<identifier>.hgrm:This file is updated in its entirety with each recording interval.It contains detailed histogram data showing the distribution ofhiccup duration by percentile for the entire jHiccup run.
ANALYZING JHICCUP DATA &CARTS The data collected by jHiccup represents actual stall times observedon the runtime platform (at the JVM level and below) while theapplication being monitored is actually running on it. While jHiccupdoes not measure application response times, application responsetime will inevitably include any stall times observed at the runtimeplatform level. jHiccups Hiccup Charts, at any time point and at anypercentile, represent the absolute "best case" scenario data forapplication response times - the time in which an empty amount ofwork could be done. jHiccup data and Hiccup Charts can quicklyidentify whether application responsiveness issues are dominated byapplication code or by the underlying runtime platforms behavior:1. If application response time behavior is similar to that observed by jHiccup, observed as acorrelation of dominant stall events in time and of response time %ile distribution andmagnitude, the runtime platforms behavior and occasional stalls are likely the dominantfactor in application responsiveness. Improvement in runtime stall behavior throughtuning or eliminating runtime stall causes will most likely improve the application responsetime characteristics.2. If application response time behavior does not correlate with jHiccup data and HiccupCharts, the application code and/or external resources are most likely the dominantfactor, and runtime tuning and improvements in the area of stalls and responsiveness areunlikely to result in improved application response behavior.