| United States-English |
|
|
|
![]() |
HPjmeter Version 3.1 User's Guide > Chapter 9 Understanding How HPjmeter Works Performance Overhead on Running Applications |
|
HPjmeter is designed to minimize data collection overhead on deployed applications. The most significant change you will notice is slightly longer application server startup times. HPjmeter uses load-time bytecode instrumentation to reduce overhead in deployment situations. The load-time processing increases application server startup time, the time from invoking the application server startup script until the application server is ready to accept requests, by several minutes. This overhead also allows HPjmeter to avoid preprocessing application server or user code. HPjmeter provides lightweight data collection designed for deployment-time monitoring of live applications. For a typical Java application, when a session is not open (the HPjmeter JVM agent is in dormant mode), the application overhead is very low. When a session is open and collecting data (active mode), overhead is higher than in dormant mode with default settings , but still is typically low. Once a session is closed, overhead returns to a very low level. Overhead depends on the set of filters and flags you specify. To minimize overhead, you can use the nohotspots and noalloc options to disable the Java Method HotSpots and Object Allocation metrics for the lifetime of the JVM agent. Using include and exclude filters, may increase or decrease overhead, respectively. The include option provides more monitoring detail but increases overhead while the exclude option decreases overhead by providing less monitoring detail. By default, application server classes are not instrumented, which minimizes overhead and focuses measurements on your code. A major side effect of profiling is that the profiling itself consumes memory and CPU time. This introduces two problems. One is overhead - you'll notice that the profiling runs take longer than normal runs—sometimes substantially longer. The other problem is intrusion. When the metrics collection uses the same resources that you want to measure, you get the numbers not only for the application, but rather for the application plus whatever you use to collect the metrics. CPU usage is negligible for a node agent with no connections, a node agent without a console attached, and a node agent with a small number of open sessions. The reason is that the node agent spends almost all its time blocked on socket and first-in first-out (fifo) waits. When the node agent is managing open sessions, overhead is extremely low. The physical memory footprint of the node agent is about 1 MB when idle and 1.5 MB when active. |
||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||