If you’ve been looking for deeper insight into your JVM and application server, we’ve got some good news for you. The latest release of the New Relic Java agent includes an increase in the amount of data we collect on your Java applications and these new metrics can be used to solve a multitude of performance problems.
The new metrics are located under the JVM tab and include the following:
* Loaded and unloaded class count for the JVM
* Active thread count for the JVM
* Active and idle thread count for each thread pool
* The ratio of active to maximum thread count for each thread pool
* Active, expired and rejected HTTP session counts per application
* Active, finished and created transaction counts per application server
Now let’s take a closer look at each of them:
Loaded & Unloaded Class Count
Location: Under the Memory tab in the bottom-right corner of the screen.
Supported Application Servers: All application servers that have JMX enabled.
Use Cases: The loaded and unloaded class count can be used for a variety of purposes. For example, if the loaded class count is constantly going up, then the app server or a class loader may have a bug. Or if you perform upgrades without bringing down the JVM, you can use it to verify that classes were unloaded and then reloaded.
Active Thread Count
Location: Under the Threads tab.
Supported Application Servers: All application servers that have JMX enabled.
Use Cases: You can use the thread count to determine how many active threads are running in your application. This is useful for determining usage trends. For example, it can show the time of day and the day of the week in which you usually reach peak thread count. In addition, the creation of too many threads can result in out of memory errors or thrashing. By watching this metric, you can reduce excessive memory consumption before it’s too late.
Thread Pool Metrics
Location: Under the Threads tab.
Supported Application Servers: Tomcat, JBoss 5 and 6, Resin, Jetty, WebLogic, TomEE, Glassfish, and WebSphere
Use Cases: Thread pools are typically used to service multiple requests simultaneously. However, to get the best throughput, thread pools must be configured appropriately. For example, if the maximum thread count is set too high, the app will slow down from excessive memory usage. But if the maximum thread count is too low, it will cause requests to block or timeout.
You can use these metrics to see if you are reaching the maximum thread count in a pool. In addition, they can be used to tune other properties – such as the amount of time before an idle thread is destroyed and the frequency of when new threads are created.
This graph displays information on the http-bio-8080 thread pool on a Tomcat 7.0 application server. It shows that the thread pool starts with 10 idle threads and never handles more than five active requests at a time. The 0.23% capacity indicates that the number of active threads is well under the limit.
Session Metrics
Location: Under the HTTP Sessions tab.
Supported Application Servers: Tomcat, JBoss 5 and 6, Resin, TomEE, Glassfish, and WebSphere
Use Cases: HTTP session information is used to determine usage trends such as the time of day when an application is getting the most amount of traffic. It can also be used to tune configuration properties such as the maximum number of active sessions allowed at one time and the amount of time a session remains active. For example, a high rejected session count usually indicates that the maximum active session count should be increased. Meanwhile, a high expired session count can suggest that the session timeout is too low.
The graphs below show session information for two applications. The first indicates that a maximum of two sessions have been created for the application ‘examples’, but the sessions are constantly expiring. After increasing the timeout, the number of expired sessions reduces to zero. From the second graph, we see that zero sessions have been created for the application ‘host-manager’.
Transaction Metrics
Location: Under the App Server Transaction tab.
Supported Application Servers: JBoss 7, Resin, and Glassfish
Use Cases: These metrics show info on transactions that go through the application server's transaction manager. They are used to show transaction traffic patterns and help to configure the transaction manager.
Get Started Today
New Relic uses Java Management Extensions (JMX) to gather data on these new metrics. Before you get started using these new metrics, you must update to our latest Java agent and enable JMX on your application server.
You can also set up New Relic to show custom JMX metrics. To see how to display custom metrics, watch this video.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.
