Re: Training in Green Screen Java performance and debugging?

Luis Colorado skrev den 11-12-2007 22:48:

the spool file on the debug level, and on info or higher to long term storage in actual IFS files.

I think that logging is always nice, but please consider that the iSeries provides some nice logging by default. If I try the following:

sbmjob cmd(RUNJVA CLASS('HelloWorld'))

It will fail because there is no 'HelloWorld' class in my classpath. If I run the following command:

wrksbmjob

I see my last two jobs (there might be more old jobs out there). One job type is BATCH, and the other is BATCHI. If I do option 8 to any of them, I can see several job logs that I can view. Have you tried something like that?

Yes, we have looked into this. What we need logging for is post-mortem analysis, so it is a matter of being able to put context on a stack trace.

I read an article about always logging everything which struck a note, so I am following this thought for a while. I have experimented with the Java 5 instrumentation mechanism to add logging at runtime to classes without logging, which is very promising.

Well, your PC might look faster that your iSeries (and that might be true in a way), but there are several things to remember:

1. Your java job does not use the 100% of the processor when it starts. Even if you change the priority to a very low number (I would not recommend less than 20, because you would affect interactive users), the operating system will not give it a decent slice of the processor to your job until some time has passed. Thus, java jobs look slower. 2. Many iseries have multiple processors, even the old systems. Most of the time a job uses only one processor. I don't know if java multithreading uses multiple processors effectively, but you might want try that (and report your results, please!). Another technique is to launch multiple batch jobs listening to a data queue for data. This is pretty powerful. I can give you more details if you want.
3. The iSeries hardware is optimized by design for *heavy* input/output. The rationale is that business applications make a heavier use of disk (database) than processing.. Although pure processor performance may be lackluster, input/output and database operations are quite surprising (and very stable).

I do not have admin-fu to change anything regarding resource allocation. I just need to be able to say that this machine is perceived slower than that machine due to XXX and here is the data to support it.

This is interesting. I was unaware of that. Thanks for the info! I think that the *JIT is relatively new, and I had not tested it.

You are welcome. But this was still much slower than a PC - our only reason for doing this on the AS/400 is that the conversion was a bridge between two native AS/400 products.

I still need to check if the JIT allows hot deployment of new code - the classic JVM (Direct Execution) do not.