Download ppt - CMG Canada Home Page

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Java Performance on
z/OS: A Report From
the Front Lines
Craig Hodgins
Paper 5047
CMG2005
Session 332
Agenda
A Brief History of Java
Why Java Matters on the Mainframe
An Overview of Java for Mainframers
Review of Two STROBE Measurements
JVM CPU
JITC CPU
JAVAJIT CPU
ZIP files
Java CPU Overhead (logging, security)
Java Methods
CMG2005
Summary
A Brief History of Java
10 years old
Developed at Sun Microsystems as an
embedded language for household
appliances
Redesigned to work with cable TV
Language of choice for the Internet
Still used as an embedded language
CMG2005
Why Java Matters on the
Mainframe
IBM developed WebSphere Application Server
Enables organizations to utilize Java
applications under z/OS
Java is frequently the biggest consumer of
CPU in a WAS environment
Java is replacing COBOL as the language of
choice
But Java consumes 5 to 10 times more CPU
than COBOL does for the same function
CMG2005
What is Java?
Java is not…
… a 1960’s reference to coffee
… an island in the Pacific
CMG2005
What is Java?
An object-oriented language
Objects (bank account)
Methods (withdrawal, deposit, open,
close)
CMG2005
Components of Java
Applets are Java programs running in a web
browser
Servlets are Java programs running in a web
server
JavaServer Pages (JSPs) display data to the
user
Enterprise Java Beans (EJBs) are serverside components that contain business logic
Most of these components can execute
under WAS on z/OS
CMG2005
Java / COBOL
Java method contains multiple statements
and is like a COBOL CSECT
Java class contains multiple methods and is
like a COBOL load module
A Java package is an organizational tool
similar to a high level qualifier or a Windows
directory
A Java CLASSPATH is similar to a library in
z/OS or a PATH in Windows
CMG2005
The Java Call Stack
As the Java application executes, memory is
allocated in the Java Call Stack
Frames are pushed and popped on and off the
stack as the methods are invoked
The state of the Java Call Stack reflects the
chain of methods from the initial method called
to the current method that is executing
CMG2005
Java Call Stack
com.compuware.PayRoll.main(void)

com.compuware.Payroll.CalculateSalary(…)

com.compuware.Payroll.ComputeOverTime(…)

java.lang.String.CharAt(…)

java.lang.String.toLowerCase(…)
Java
Application
Call Stack

The Call Stack is an area of memory that
maintains the order in which Java methods
are executed

When a method is invoked, a “Stack Frame”
is “pushed” to the top stack of the stack

When the method is completed, it is
“popped” off the stack
CMG2005
top  toLowerCase
CharAt
ComputeOverTime
CalculateSalary
bottom  main
WAS Architecture
CMG2005
Session duration 15 minutes
CPS 40.57%
Wait 59.43%
CMG2005
CPU 5 min
Java 41.55%
Libjvm 29.70%
CMG2005
JVM CPU Usage
JVM is the environmental code
Java engine that manages the components
Usually consumes around 25-35% of the CPU
If JVM CPU seems high:
upgrade to a newer release
apply latest maintenance
CMG2005
Libjitc 4.13%
CMG2005
JITC CPU Usage
Java is interpreted by default
IBM introduced a Just-in-Time Compiler that
will compile methods on the fly
MMI (Mixed Mode Interpreter) parm sets
threshold that must be reached before
compilation
Forces distribution of compilation
overhead…
CMG2005
JITC CPU Usage
… when the JVM initiates, thousands of
methods are executed
Significant overhead all at once as methods
are compiled
Possible that it may take longer to initiate the
JVM than run the application
CMG2005
JITC CPU Usage
JIT on, MMI on (default)
JVM will start relatively quickly (interpreted)
and runtime performance will improve over time (JITC)
JIT off, MMI off
JVM will start quickly, but runtime execution
will be slow (interpreted)
JIT on, MMI off (forces compilation only)
JVM will start slowly but runtime will be
optimized
CMG2005
JAVAJIT CPU Usage
JAVAJIT is the CPU consumed by the total compiled
methods in the measurement
CMG2005
Libjitc 26.51%
JAVAJIT 16.17%
CMG2005
JAVAJIT 50.01%
Libjitc 4.13%
CMG2005
Libzip 5.54%
CMG2005
ZIP Files
ZIP files are used to combine multiple class files
into one file to reduce I/O overhead, load time, or
file transfer time
5.54% may be acceptable (must determine your
own benchmarks)
Recommendation is to use uncompressed ZIP or
JAR files to reduce compression overhead
CMG2005
Class Loading
JVM searches the directories in the order they
are listed in the CLASSPATH environment
variable
Class loader has two modes
Application mode: search first within the
application directory and then the IBM
directory
J2EE mode: search first in the IBM directory
and then the application directory
CMG2005
Class Loading
Paths should be reordered so that the most
used libraries are found first
Package the classes in the order in which
they are loaded by the application
Do not add unnecessary class files to avoid
large files and extra memory usage
CMG2005
JAVA CPU Overhead
Computers make it easier to do a lot of things,
but most of the things they make it easier to do
don’t need to be done.
Andy Rooney
CMG2005
JAVA CPU Overhead
Hierarchical method invocation requires
extra processing for each method call to
determine the target (build the call stack)
Keep current on JVM releases and
maintenance levels
Security checks consume CPU (eg 7.6%)
Tuning security is a trade-off between
performance and integrity
CMG2005
JAVA CPU Overhead
Logging always degrades performance
Documented techniques to have logging turned
on in test but turned off in production
Different levels of logging can be customized
CMG2005
Rtrim 3.41%
CMG2005
RTRIM Method
Inhouse routine to strip off rightmost bytes of data
Developer thought it may be possible to rewrite the
application such that RTRIM was not required
CMG2005
The Cost of the RTRIM
Method
Measurement was for 15 minutes, CPU time
was 5 minutes:
WAS CPU per hour = 5 minutes x 4 = 20
minutes
WAS CPU per year = .3 X 8760 = 2628 hours
RTRIM CPU per year = 3.41% of 2628 = 89 hours
Total dollar cost of RTRIM per year = $550.00 X 89 =
$48,950.00
May run in other applications and multiple WAS
CMG2005
MicroValidator 1.65%
validateField 0.59%
CMG2005
Validate Method
Some kind of validation process
Can it be done on another platform?
Some less expensive way of
validating?
CMG2005
String 3.32%
StringBuffer 1.10%
CMG2005
Text Processing (Strings)
Strings are immutable
Cannot be modified
A new StringBuffer object will be
created under the covers
A new String object is returned
via the toString method
Beware of text processing in
loops
CMG2005
Text Processing (Strings)
Several methods generate new
instances of objects:
concat
replace
substring
trim
CMG2005
Text Processing (Strings)
StringBuffers are modifiable
Use them to avoid creating
temporary String objects
Possible alternative solution:
use character arrays instead of
strings
CMG2005
toUpperCase
toLowerCase
CMG2005
Text Processing (Strings)
Why are we using these
methods?
Can they be done on another
platform?
Is there a better way?
CMG2005
Text Processing (Strings)
When parsing a string, pass the
length as a parm
Otherwise Java must make many
calls to the String.length method
Use char arrays rather than
using String.charAt
CMG2005
Summary
JVM – keep up with maintenance
JITC – optimize MMI parm
ZIP – use judiciously
Methods – Always question things:
Ask “Why?” Ask “How?” Ask
“Is there a better way?”
CMG2005
Summary
The opposite of a correct statement is a false
statement. The opposite of a profound truth
may well be another profound truth.
Niels Bohr, Quantum Physicist
Common sense is not very common – Latin
proverb
CMG2005
Further Reading
Diagnostics Guide JDK 1.3.1 (SC34-6200-02)
Java Performance Tuning, Jack Shirazi
www.javaperformancetuning.com
Other books, other websites
CMG2005
Final Thought
No matter what kind of system we have or
what the application is, nothing in
computer work seems to go as quickly as
we think it should. The faster computers
move, the more they try our patience. We
get a more powerful machine and it still
doesn’t process fast enough to satisfy
us. Simple as a task might seem to finish,
it inevitably takes longer than predicted.
There’s always one more thing to get
right, to tweak, to test again.
Zen Computer
CMG2005
Thank you
[email protected]
CMG2005