Re: AS/400 and Java

Hi,

and here my performance tips:

1. read the recent manuals (Performance Capabilities Reference
recommends the JIT environment since V4R5!)
2. don't use CRTJVAPGM on boxes > V4R5
3. don't use the native driver, its buggy, use the latest Toolbox
driver
4. don't use record level access (more IO Operations compared to SQL)
5. run your application server on inexpensive boxes (Wintel, or Linux
on Intel), if possible (scalability)
6. Don't mix Java with RPG and/or COBOL, the context change is very
expensive
7. use all features of the as400 as database server, you've paid for
it
8. for maximal speed with minimal hardware requirements use assembler
and shift your bytes bit by bit

Dieter


Danny Oentung schrieb:
> i've read a lot of benchmark that ibmers say that they've
> achieved like
> Volano, SPECjbb2000, and the result is good but i am not
> sure that is it
> perform the same with all the iseries server
> http://www.spec.org/osg/jbb2000/results/jbb2000.html
> . anyway it is good to hear things all people's
> experience in running java
> app. in iseries.
>
> maybe this could help (ps:if you have read this or a
> newer version, just
> ignore it :)
> AS/400 Java Performance Tuning (for V4R2) Tips (or go to
> :http://www-919.ibm.com/developer/java/faq/perffaq.html#1)
>
>
> AS/400 Java Performance Tuning (for V4R2) Tips
> Introduction
> You asked for it, and now it is here. The AS/400 Java
> Performance Tips. Keep
> watching this page as it evolves. If you have any
> questions, or would like
> to share a tip, use the "Feedback" button at the top of
> this page.
>
> Table of Contents
> Top Tips
>
>
> Load the latest CUM package and PTFs
> Use CRTJVAPGM on .zip and .jar and .class files
> Use the native JDBC driver or ToolBox record I/O for
> local AS/400 data
> access
> Leave GCHMAX as default; Adjust GCHINL and GCHPTY as
> necessary; Ignore
> GCHFRQ
> Minimize the use of String Objects
> Minimize object creation
> Minimize synchronized methods
> Use Prepared Statements
> AS/400 Java Tips
>
>
> Load the latest CUM package and PTFs
> Use CRTJVAPGM on .class files
> Use CRTJVAPGM on .zip and .jar files
>
> Java Language Performance Tips
>
>
> Minimize synchronized methods
> Use the -O javac option
> Minimize object creation
> Minimize the use of String objects
> Leverage variable scoping
> Minimize use of exceptions
> Minimize JVM start up
> Use static final when creating constants
>
> AS/400 Database Access Tips
>
>
> Use the native JDBC driver
> Use Prepared Statements
> Store character data in DB2 as Unicode
> Store numeric data in DB2 as float
> Use ToolBox record I/O
> Check ToolBox for existence of a Java program object
> Close statement objects before recreating similar
> statements
> Use getField() rather than getFields() in Toolbox
> recordaccess
> Use get...(int columnIndex) rather than get...(String
> columnName)
>
> Garbage Collection Tips
>
>
> Leave GCHMAX as default
> Adjust GCHINL as necessary
> Adjust GCHPTY as necessary
> Ignore GCHFRQ
> Monitor GC Heap faulting
> Introduction | Table of Contents | The Good Stuff !!
>
>
>
----------------------------------------------------------------------------
> ----
>
> The Good Stuff
> AS/400 Java Tips
>
>
> Load the latest CUM package and PTFs
>
> To be sure that you have the best performing code, be
> sure to load the
> latest CUM packages and PTFs for all products that you
> are using.
> Information on the AS/400 JVM can be found at the
> Developer Kit for Java Web
> Site. Information on the IBM Toolbox for Java can be
> found at the Toolbox
> Web Site.
>
>
> Use CRTJVAPGM on .class files
>
> Java .class files should be converted into direct
> execution (machine
> instruction) Java program objects through the CRTJVAPGM
> command. Use this
> command before running any Java programs. The Program
> object is permanent
> and will be re-used once it is created. Use the DSPJVAPGM
> command to
> determine if the Java Program Object exists. Optimization
> levels 10,20,30
> and 40 are supported on the CRTJVAPGM command
>
> Relative Performance:
> Results will vary by application. For computation and
> call intensive
> applications the relative gains can be dramatic. Here are
> the relative
> performance gains for Towers of Hanoi.
>
>       Relative time
> Optimization level 40       1.00
> Optimization level 30       1.73
> Optimization level 20       2.02
> Optimization level 10       2.65
> Interpretive       12.95
>
>
> Comparisons based on v4r2. JDK 1.1.4.
>
>
> Use CRTJVAPGM on .zip and .jar files
>
> CRTJVAPGM must be used on .zip and .jar files. If the
> CRTJVAPGM was not run,
> the JAVA/RUNJVA command will implicitly create program
> objects for each
> class file in a .zip or .jar. Unlike a .class file
> however, these program
> objects are not saved. The implicit creation of program
> objects will
> significantly impact JVM startup or class loading. The
> implicit creation
> will occur every time you start the JVM. To determine if
> your .zip/.jar file
> has a permanent program object use the DSPJVAPGM
> command.
>
> NOTE 1: Packaging multiple classes in one .zip or .jar
> file may also improve
> class loading time and code optimization.
>
> NOTE 2: If using the IBM Toolbox for Java classes on
> v4r2, you will need to
> perform CRTJVAPGM on jt400.zip and jt400.jar.
>
> Java Language Performance Tips
>
>
> Minimize synchronized methods
>
> Synchronized method calls take at least 10 times more
> processing than a
> non-synchronized method call. Synchronized methods are
> only necessary if you
> have multiple threads sharing the same object. If you
> share objects between
> threads, keep the duration of the synchronized method low
> to improve
> parallel execution.
>
>
> Use the -O javac option
>
> The javac compiler may in-line methods if the -O option
> is selected. In
> order for a method to be in-lined it must be a final
> method (static, final,
> or protected). Final methods can not be subclassed, which
> is the key to
> allowing in-lining. Method in-lining is not supported in
> the AS/400 JVM
> other than through the -O option.
>
>
> Minimize object creation
>
> Object creation can occur implicitly within the Java
> api's that you use as
> well as within your program. Object creation and the
> resulting garbage
> collection can typically take 15% of a server transaction
> workload. To
> minimize this cost you can reuse objects by implementing
> a "reset" method
> that clears the local variables in the object. The code
> fragment
> if objx = null then
>       objx = new x();
> else
>       objx.reset();
>
> can provide significant performance improvements.
>
>
> Minimize the use of String objects
>
> String objects in Java are immutable. This means that you
> can not change
> (append, etc.) to a string object without creating a new
> object. Object
> creation is expensive and can occur multiple times for
> each String object
> you are using. To minimize the use of String objects you
> should use either
> StringBuffer or Char[]. StringBuffer may also be a
> problem since the
> StringBuffer classes use synchronized method calls. An
> array of characters
> (char[]) can be used to simulate fixed length strings.
> This is recommended
> for applications which make heavy use of string data.
>
> Relative Performance:
> The following table shows the relative performance
> difference when using
> String, StringBuffer, or char[]. The test case
> concatenates two strings. For
> the char[] case. the concatentation reduces to simple
> array assignment, thus
> avoiding the creation of objects and the synchronization
> overhead associated
> with StringBuffer. In the following table the String
> "World Wide" was
> concatenated to the string "Wait". For the Char[] test
> there were simply
> four char[] assigments for the characters 'W' 'A' 'I'
> 'T'.
>
>       Relative time
> char[]       1
> StringBuffer       35
> String       363
>
>
> Comparisons based on Optimization level 40, v4r2. JDK
> 1.1.4.
>
>
> Leverage variable scoping
>
> Java supports multiple techniques for accessing
> variables. One typical
> technique is to write an "accessor" method. Local
> variables are the fastest.
>
>
> Relative performance:
> Here are five comparisons on variable access time and
> their relative
> performance. A local variable is the fastest and is given
> a relative
> performance of 1.       Relative time
> Local variable :       1.0
> Instance variable:       2.0
> Accessor method in-lined:       2.0
> Accessor method:       5.9
> Synchronized accessor method:       99.6
>
>
> Comparisons based on Optimization level 40, v4r2. JDK
> 1.1.4.
>
>
> Minimize use of exceptions
>
> In v4r2 Java exceptions use the full ILE exception
> handling mechanism. This
> is a relatively expensive operation. Significant
> improvements are planned in
> the next release. As with any JVM however, exceptions
> should be used for
> error conditions that occur infrequently.
>
>
> Minimize JVM start up
>
> The JAVA/RUNJVA commands create a new batch immediate Job
> to run the JVM.
> Limit this operation to relatively long running Java
> programs. If you need
> to invoke Java frequently from non-Java programs consider
> passing messages
> through an AS/400 Data Queue. The ToolBox Data Queue
> classes may be used to
> implement "hot" JVM's.
>
>
> Use static final when creating constants
>
> When data is invariant, declare it as static final. For
> example here are two
> array initializations:
>         class test1 {
>               int myarray[] = { 1,2,3,4,5,6,7,8,9,10,
>                                 2,3,4,5,6,7,8,9,10,11,
>                                 3,4,5,6,7,8,9,10,11,12,
>                                 4,5,6,7,8,9,10,11,12,13,
>                                 5,6,7,8,9,10,11,12,13,14
> };
>               {
>
>         class test2 {
>               static final int myarray2[] = {
> 1,2,3,4,5,6,7,8,9,10,
>
> 2,3,4,5,6,7,8,9,10,11,
>
> 3,4,5,6,7,8,9,10,11,12,
>
> 4,5,6,7,8,9,10,11,12,13,
>               }
> 5,6,7,8,9,10,11,12,13,14 };
>
>
>
>
> Relative Performance:
> When 10,000 objects of type test1 and test2 were created
> the relative time
> for test1 was about 2.3x longer than test2. The test
> saved each array object
> to avoid any garbage collection.
>
> Comparisons based on Optimization level 40, v4r2. JDK
> 1.1.4.
>
> AS/400 Database Access Tips
>
>
> Use the native JDBC driver
>
> There are two AS/400 JDBC drivers that may be used to
> access local data. The
> Toolbox driver is located at URL "jdbc:as400:system-name"
> where system-name
> is the AS/400 tcp/ip system name. The native JDBC driver
> is located at URL
> "jdbc:db2:system-name" where the system-name is the Data
> Base name. The
> native AS/400 JDBC driver uses an internal shared memory
> condition variable
> to communicate with the SQL/CLI Server Job. The ToolBox
> JDBC driver assumes
> that the data is remote and uses a socket connection into
> the client access
> ODBC driver. The native JDBC driver is faster when you
> are accessing local
> data.
>
>
> Use Prepared Statements
>
> The JDBC prepareStatement should be used for repeatable
> executeQuery or
> executeUpdate methods. If prepareStatement is not used,
> the execute
> statement will cause an implicit prepareStatement every
> time the execute
> statement is run.
>
>
> Store character data in DB2 as Unicode
>
> The AS/400 JVM stores string data internally as 2 byte
> Unicode. If you are
> reading or writing large amounts of string data and the
> data is stored in
> EBCDIC, the data will be converted on every database
> access. You can avoid
> this conversion by storing the data in DB2 as 2 byte
> Unicode. Use the SQL
> graphic type with CCID 13488 or the DDS grahic type with
> CCID 13488.
>
>
> Store numeric data in DB2 as float
>
> Decimal data can not be represented in Java as a
> primitive type. Decimal
> data is converted to the abstract class
> Java.lang.BigDecimal on every
> database read or write. This conversion can be avoided by
> storing numberic
> data in the database as float or double. Alternatively,
> you may considering
> converting the BigDecimal type to float for heavy
> calculations while leaving
> the Database in decimal form. Note that rounding
> differences may be
> introduced with the use of float or double.
>
>
> Use ToolBox record I/O
>
> The IBM Toolbox for Java provides native record level
> access classes. These
> classes are specific to the AS/400 platform. They provide
> a significant
> performance gain over the the use of JDBC access.
>
>
> Check ToolBox for existence of a Java program object
>
> The jt400.jar file contains the IBM Toolbox for Java
> product. After
> installation, this .jar file does not have a Java program
> object. Use the
> CRTJVAPGM at optimization level 40 to create the program
> object. See tip #3.
> Use the CRTJVAPGM command during low system activity as
> it will take some
> time. Use the DSPJVAPGM command to see if the program
> object already exists.
>
>
>
> Close statement objects before recreating similar
> statements
>
> The AS/400 attempts to reuse SQL cursors by constructing
> a cursor cache.
> Normally a cursor is created for each unique query as
> part of the
> executeQuery or executeUpdate methods. Cursors are
> available for reuse if
> they are not actively attached to a statement object. If
> you use the close()
> method on a statement, it makes the associated cursor
> eligible for reuse.
> This reuse can save a large amount of processing and is
> similar to sharing
> open files in RPG. A statement object may be eligible for
> garbage collection
> if you no longer hold a reference to that object. Garbage
> collection will
> implicitly close the statement, thus making the cursor
> elibible for reuse.
> Garbage collection points vary by application. It is
> better to close() the
> statement than to assume that cursor reuse will occur
> implicitly.
>
>
> Use getField() rather than getFields() in Toolbox
> recordaccess
>
> The ToolBox record class supports retrieving individual
> fields through
> getField() or all of the fields through getFields(). On a
> file with 9 packed
> decimal fields, 10 character fields, and one date field
> the second loop
> takes about 2 times longer than the first loop. Since
> most applications do
> not need all of the fields in a record. It is better to
> use getField on only
> the fields used by the application.
>
>
>
>       partialKey[0] = new BigDecimal("-2");
>       partialKey[1] = new BigDecimal("-5");
>
>
>         //
>       for (int i = 0; i < RowCntArg; i++) {
>          partialKey[0] =
> ((BigDecimal)partialKey[0]).add(EIGHT);
>
>           ...
>           tablexdata = file.read(partialKey); // reads record
> no
> conversion
>             ...
>       {
>
>         Object[] fieldobj = null;
>         for (int i = 0; i < RowCntArg; i++) {
>          partialKey[0] =
> ((BigDecimal)partialKey[0]).add(EIGHT);
>           ...
>
>           tablexdata = file.read(partialKey);
>             ...
>             fieldobj = tablexdata.getFields(); // Will
> convert every field
> to a Java type
>             ...
>          {
>
>
> Use get...(int columnIndex) rather than get...(String
> columnName)
>
> Depending on the number of columns in your result set,a
> getxx field
> operation using the columnIndex is about 2 times faster
> than a getxx field
> operation using the columnName. There is an application
> consideration
> however when using getxx columnIndex in that your
> application becomes more
> dependent on the order of the columns in the result set.
> Note that on some
> JDBC drivers, the retrieval of columns by index is
> limited to ever
> increasing index values. This is not a restriction on
> AS/400 JDBC drivers.
>
> Garbage Collection
>
>
> Leave GCHMAX as default
>
> The GCHMAX parameter on the JAVA/RUNJVA command specifies
> the maximum amount
> of storage that you want to allocate to the garbage
> collection heap. In
> general the default value (set to the largest possible
> value) should be
> used. The system does not allocate the storage until it
> is needed. A large
> value should not impact performance. If this maximum is
> reached, the JVM
> will stop all threads and attempt to synchronously
> collect objects. Setting
> this value to a small number may force unnecessary
> synchronous collections.
>
>
> Adjust GCHINL as necessary
>
> The GCHINL parameter on the JAVA/RUNJVA command specifies
> the amount of
> initial storage that you want to allocate to the garbage
> collection heap.
> This parameter indirectly affects the frequency of the
> asynchronous garbage
> collection processing. Each time the total allocation for
> new objects
> reaches this value, asynchronous collection is started.
> This parameter is
> application dependent and may require some adjustment.
>
>
> Adjust GCHPTY as necessary
>
> This parameter affects the relative priority of the
> garbage collection
> thread. A higher priority value will reduce the amount of
> time spent in the
> asynchronous portion of the collection. You should not
> adjust this value
> unless the application is memory constrained.
>
>
> Ignore GCHFRQ
>
> This parameter is not used. It has no effect on
> performance.
>
>
> Monitor GC Heap faulting
>
> Java objects are maintained in the JVM heap. Excessive
> page faults may occur
> if the memory pool for your JVM is too small. These
> faults will be reported
> as non-database page faults on the WRKSYSSTS command
> display. Typically the
> storage pool for your JVM is *INTERACT. Fault rates
> between 20 and 30 per
> second are acceptable. Higher rates should be reduced by
> increasing memory
> pool size.
>
>
> Introduction | Table of Contents | The Good Stuff !!
>
>
>
>
>
>   About IBM   |   Privacy   |   Legal   |   Contact
> _______________________________________________
> This is the Java Programming on and around the iSeries /
> AS400 (JAVA400-L) mailing list
> To post a message email: JAVA400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/cgi-bin/listinfo/java400-l
> or email: JAVA400-L-request@midrange.com
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/java400-l.
>
>