Many applications export performance data through JMX attributes.
While profiling, it can be useful to correlate these with the built-in performance graphs that YK already supports.
Ideally, I could configure ObjectName+AttributeName pairs, and YK would remember these, allowing me to add graphs for those attributes to the "Performance Charts" view.
Obviously this would only work for numeric JMX attributes (Number subtypes and primitive number types).
Performance charts: JMX attribute support
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: Performance charts: JMX attribute support
Hi,
Thanks for the suggestion.
Perhaps we should have a predefined set to start with.
Do you like this idea? If yes, do you have good candidates to include?
Another question: are you mostly interested in standard beans, or in custom (server-specific?) beans?
Alternative approach is to offer all discovered pairs offered by default, but I guess there would be too many of them. Or not?
Best regards,
Anton
Thanks for the suggestion.
If the list is initially empty, it will be difficult to discover and start using the feature.Ideally, I could configure ObjectName+AttributeName pairs, and YK would remember these, allowing me to add graphs for those attributes to the "Performance Charts" view.
Perhaps we should have a predefined set to start with.
Do you like this idea? If yes, do you have good candidates to include?
Another question: are you mostly interested in standard beans, or in custom (server-specific?) beans?
Alternative approach is to offer all discovered pairs offered by default, but I guess there would be too many of them. Or not?
Best regards,
Anton
-
- Posts: 314
- Joined: Thu Jun 02, 2005 8:36 pm
Re: Performance charts: JMX attribute support
Hi Anton,
I did not think about the UI for this.
In our case, we are typically interested in custom beans, either application specific, or exposed by frameworks like Hibernate.
The data exposed by the JVM built-in JMX beans (memory/GC etc) is mostly already exposed by YK through other means (JVMTI, I assume).
There are a few potentially interesting JVM MBean properties to expose by default (as an example, as you suggest). I'll see if I can suggest some candidates.
In our applications, we typically have hundreds of numeric bean properties that could be graphed, so simply including all of them by default would not be a good approach.
A dialog with "SpeedSearch" matching part of bean name or property name would be great. I would expect such a search to work against the set of beans registered in the platform MBeanServer of the JVM the profiler is currently attached to. The dialog would show the matches based on my search string, and allow me to select one or more to show live charts for.
Saving such "preferred" graph-able properties would be very convenient, however next time I might be connected to a different application, and it will have a different set of MBeans available. Perhaps persisting such MBean "favorites" is a feature for later, after providing the basic "find&graph" support described above.
Kind regards,
Taras
I did not think about the UI for this.
In our case, we are typically interested in custom beans, either application specific, or exposed by frameworks like Hibernate.
The data exposed by the JVM built-in JMX beans (memory/GC etc) is mostly already exposed by YK through other means (JVMTI, I assume).
There are a few potentially interesting JVM MBean properties to expose by default (as an example, as you suggest). I'll see if I can suggest some candidates.
In our applications, we typically have hundreds of numeric bean properties that could be graphed, so simply including all of them by default would not be a good approach.
A dialog with "SpeedSearch" matching part of bean name or property name would be great. I would expect such a search to work against the set of beans registered in the platform MBeanServer of the JVM the profiler is currently attached to. The dialog would show the matches based on my search string, and allow me to select one or more to show live charts for.
Saving such "preferred" graph-able properties would be very convenient, however next time I might be connected to a different application, and it will have a different set of MBeans available. Perhaps persisting such MBean "favorites" is a feature for later, after providing the basic "find&graph" support described above.
Kind regards,
Taras