Best Practices for performance evaluation and diagnosis of Java Applications [5th IndicThreads.com Conference On Java]
Session Presented at 5th IndicThreads.com Conference On Java held on 10-11 December 2010 in Pune, India WEB: http://J10.IndicThreads.com ------------ Enterprise applications typically comprise of multi layered stacks including the application modules, application servers, the Java Virtual Machine and the underlying Operating System. Consequently the performance of these applications are a factor of these different layers. In the eventuality of a performance problem, it is often difficult to determine the starting point for diagnosis. The Java Virtual Machine is the ‘engine’ for most of the applications. It is responsible broadly for efficient execution and memory management of applications. End users have difficulty attributing the effect of the JVM on the performance of the application. This is because usually JVM is viewed as a ‘black box’. This talk provides an insight into the key subsystems of the JVM by looking under the hood of a high performance JVM. It ventures onto talk about approaches and techniques for analyzing performance issues. It concludes by introducing the audience to a tool called the “Health Center” which is useful for evaluating and comprehending the JVM behavior of a running application in an unobtrusive, lightweight manner. Takeaways for the Audience A better understanding of key JVM components, approaches and techniques to diagnose performance issues and performance evaluation using the Health Center
![Agenda ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Best Practices for performance evaluation and diagnosis of Java Applications [5th IndicThreads.com Conference On Java]
Similar a Best Practices for performance evaluation and diagnosis of Java Applications [5th IndicThreads.com Conference On Java] (20)
Más de IndicThreads
Más de IndicThreads (20)
Último
Último (20)
Best Practices for performance evaluation and diagnosis of Java Applications [5th IndicThreads.com Conference On Java]
- 1. Best Practices for Performance Evaluation and Diagnosis of Java Applications Prashanth K Nageshappa Venkataraghavan Lakshminarayanachar IBM
- 4. Lifting the Hood Overall Architecture User Code VM Extensions Core VM Portability Layer Operating systems Debugger Profilers Java Application Code JVMTI SE5 Classes SE6 Classes Harmony Classes User Natives GC JIT Class Library Natives Pluggable VM Interfaces Java Native Interface (JNI) Core VM (Interpreter, Verifier, Stack Walker) Trace & Dump Engines Port Library (Files, Sockets, Memory) Thread Library AIX Linux Windows z/OS PPC-32 PPC-64 x86-32 x86-64 PPC-32 PPC-64 390-31 390-64 x86-32 x86-64 390-31 390-64 = User Code = Java Platform API = VM-aware = Core VM
- 7. Optimization and Effects n/a 9000 1322 Profiling 6187 11,000 578 Scorching 10078 4900 265 Warm Opt level Code Size (bytes) Compilation Time (us) Wall clock runtime (ms) Cold 139 2260 31685 Hot 436 8900 7765
- 16. Infrastructure and Java Runtime Issues
- 17. Application and External Issues
- 18. MustGather
- 41. Merci Grazie Gracias Obrigado Danke Japanese English French Russian German Italian Spanish Brazilian Portuguese Arabic Traditional Chinese Simplified Chinese Hindi Tamil Thai Korean Teşekkürler turkish Thank You
Notas del editor
- Notes The table gives the background for the 16 data points used in the SPECjbb2005 JVM leapfrog chart The 2 nd column “Leap vs prev”, lists how much improvement went into the JVM relative to the previous data point using a comparable Xeon chip. The 3 rd column, “Accumulated Leap vs base” lists the accumulated leaps. For example, the 4 th data point is a 17% improvement or leap compared to the 3 rd data point since the result measured in SPECjbb2005 bops improved by 17% on a comparable Xeon chip. The accumulated improvement for the 3 rd data point is listed as 1.11. The accumulated improvement for the 4 th data point is therefore 1.3x since 1.11*1.17=~1.3. An ‘a’ and a ‘b’ result, for example 3a and 3b, are two results using the same JVM on different Intel chips. This provides 2 comparison points. The actual calculation used to get the Leap data is in the ‘math’ column. The “Leap vs Prev” number is generally a simple comparison against the previous bops score on a comparable Xeon chip. The 2 nd and 3 rd data point calculations are a little more complicated. The 3 rd data point has an associated score in row 3a which was compared against the first data point, however since the clock speeds are different the leap was scaled by the clock speed differences (this is the only direct comparison that required a clock speed scaling). This calculation yields a leap of 11% The 3 rd data point has a score in the row labeled 3b which is 6% faster than the 2 nd data point. Since data point 3 is 11% ahead of data point 1 and 6% ahead of data point 2 we’ve extrapolated that data point 2 is 5% ahead data point 1. The column labeled SPECjbb2005 bops is used for all the calculated the ‘leaps’. The bops/jvm data is there for SPEC result reporting compliance.