|
Dieter, Bruce, and Mark, The CRTJVAPGM command is still useful and can dramatically improve performance even on the latest release. For example, an uncompiled version of Tomcat and our site takes at least 5 minutes to start w/o compilation. With compilation it takes less than 2 minutes. I don't fully understand why since most classes are loaded by a custom class loader, but I have seen it enough to know that this is absolutely the case. This can be very important when you have a short window to install upgrades, so I always compile new/changed Jar and Class files that are installed on our system. I submit these compiles to run during periods of low activity. I then create symbolic links to those Jar and Class files in our various application directories. Standalone applications tend to benefit even more from native compilation. We use JTOpen 3.2 JT400Native.jar (compiled to 40) loaded with the system class loader and have not seen any problems. This makes a big difference in performance. In our case RPG is invoked via triggers and at the native exit point to swap user/group and performance is good. David Morris >>> brucej@MRC-PRODUCTIVITY.COM 11/04/02 01:31PM >>> <zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org> wrote > 1. read the recent manuals (Performance Capabilities Reference > recommends the JIT environment since V4R5!) > 2. don't use CRTJVAPGM on boxes > V4R5 I stopped using CRTJVAPGM long ago. Everything seems to be OK. > 3. don't use the native driver, its buggy, use the latest Toolbox driver I use the native driver all the time. Everything seems to be OK. > 4. don't use record level access (more IO Operations compared to SQL) I have not used record level access. Everything seems OK. I primarily code interactive applications and SQL seems to be good enough. > 5. run your application server on inexpensive boxes (Wintel, or Linux on Intel), if possible (scalability) Linux may offer some hope. My new Intel/win2000 crashes at least once a month and they can't fix it. In 9 years I did see AS400 crash, once. > 6. Don't mix Java with RPG and/or COBOL, the context change is very expensive The context change cost probably is often more than compensated. I have a Java application that calls a big RPG program which calls other CL and RPG programs and they all do file read/update/delete. The timer shows that all these take 100 ms (0.1 second). I time it from getting a connection to returning a connection. Other applications with fewer file operations but exclusive JDBC SQL calls would always take more than 100 ms. > 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. Labor is more expensive than hardware. Bruce _______________________________________________ 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
