One of the issues I remember about QZDASOINIT was it didn't have enough "sessions". I think it's defaulted at 10, we had 100, and that still wasn't
enough. So we changed ours to 200 and the system was getting the crap beat out of it. Called in a support ticket and the recommendation was to
rebuild the interface with only one QJVACMDSRV process instead. The new Java process is multi-threaded and it handles the opens and closes much more
cleanly and it's only one multi-threaded job (typically around 43 threads). It used to continuously have around 80 QZDASOINIT sessions open at one
time. The new QJVACMDSRV typically consumes about 30% of the cpu (0.3 CPU LPAR on POWER5) while under load versus the "smaller" interface that's
still running QZDASOINIT jobs takes up between 40-45% of the cpu while under load (had to add these up on the fly, estimate). The original interface
was going well over 100% when it was tasked and the other LPAR just didn't have enough spare resources to share. That's why we had the performance
ticket opened. I think it dropped by at least a third of what it needed and ended up being much faster overall. These are all wag's on performance,
but I was watching the system while it was running, so I saw the tasks under load both before and after. There were times when the system was hitting
sustained 260% CPU used, boy that's wild to watch.
Somebody asked if the QJVACMDSRV job runs on V5R3, I want to say from memory no, but I can't be for sure. Make sure you upgrade your Java runtime
environments too. I didn't add those during the upgrade, so I CAN confirm that the QJVACMDSRV will work with Java 1.4. I only upgraded all existing
software and didn't install new software, so it's coming back to bite me on the butt.
I would love to elaborate on how we changed the configuration at the time. But I was still learning on these systems but managed to pull off a
successful OS upgrade from V5R3 to V5R4 on 6 machines. The Websphere admin was the one that fixed the interface. I'm still pretty happy about being
able to do an upgrade after 6-9 months of being on the job and never having touched an iSeries machine before. Of all the things I've learned, the
most important lesson is how "bullet proof" these machines really are.
Good luck,
Bill Epperson Jr.
Systems Communications Analyst
Memorial Health System
(719) 365-8831
Josh Diggs <JDiggs@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc
02/05/2010 12:32 PM
Subject
RE: Java performance on the i ? Good? bad? OK?
Please respond to
Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
Can you elaborate? I'm having performance issues with a java server job that I believe run out of the QZDASOINIT jobs. Is there a way to improve
performance for those jobs? I would love to see any further information you have about this.
Thanks,
josh
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of William.Epperson@xxxxxxxxxxxxxxxxxxxxxxxx
Sent: Friday, February 05, 2010 11:00 AM
To: midrange-l@xxxxxxxxxxxx
Cc: midrange-l@xxxxxxxxxxxx; midrange-l-bounces@xxxxxxxxxxxx
Subject: Re: Java performance on the i ? Good? bad? OK?
We had a similar issue with QZDASOINIT jobs on one of our i machines. We fixed one of the interfaces when we upgraded to V5R4 and changed it to the
multithreaded QJVACMDSRV job. It's taking much less overall resources and it's much faster than the older single threaded QZDASOINIT jobs. I
remember we had to change out the QAQQINI file as well. I would recommend you look at getting rid of that QZDASOINIT job and changing it. I'm still
trying to change out the other interface that's using the QZDASOINIT job(s), but management doesn't want to mess with it. It runs "good enough" to
not be the squeaky wheel at the moment.
Good luck,
Bill Epperson Jr.
Systems Communications Analyst
Memorial Health System
(719) 365-8831
James Perkins <jrperkinsjr@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc
02/05/2010 09:19 AM
Subject
Re: Java performance on the i ? Good? bad? OK?
Please respond to
Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
That sounds like a poorly designed program. It sounds like they are creating a new connection each time a user logs in. It would perform MUCH better
if they did some connection pooling instead. You would get the same result in any language. Opening and closing DB connections is expensive in any
language.
The problem is Java really isn't that hard to write. There are plenty of examples out there and people just use those examples good or bad.
The Java compiler is free and most of us use an eclipse based IDE anyway, so throwing some quick code together is easy.
Object oriented programming and procedural programming are very different. You can't code them the same way.
In RPG we take a lot of things for granted. Tables automatically open and close for us. You don't have to connect to the database and worry about
disconnecting from the database. You don't have to be concerned about thread safety. Generally speaking resources don't need to be cleaned up. People
see that you have to do that in Java and just try be smarter than the VM by NULLing objects, just not closing resources at all assuming the GC will do
it for them or connection/disconnecting from a DB for every read/write. Doing that kind of stuff can give you poor performance.
--
James R. Perkins
On Fri, Feb 5, 2010 at 07:25, Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx> wrote:
Well I do have to agree that my JAVA experience is very limited. I do
know every JAVA built application I have ever run has been extremely
slow to start up. I have also had to install old version of JAVA VM
to get applications to run, they would not with just the latest
version installed.
I also know that our programmer have written a JAVA application that
runs for the short period of a user logon to our web site. It sucks
all the CPU and memory it can. It is not running as part of a web
service on our iSeries, but under QZADOINIT jobs. I speculate that
this was not properly designed and would be better suited as an RPG application.
This job is initiated from an IIS web server to our iSeries to build
the user menu upon logon. Each Web instance creates a new QZDAOINIT
connection and JAVA instance on the iSeries so it does not take
advantage of the multithreading capability of JAVA.
I have yet to understand why the programmer used JAVA for this
application.
I can see if you are writing software to sell and need to support
Windows, Unix, Linux, and the iSeries, JAVA could help you to write it
once. Being that this company is married to the iSeries and we write
for our own use, we do not necessarily need to use a language for it's
multiplatform capacity. JAVA does offer some advantages but is not
the language for all.
When we first started parsing XML, we used a JAVA XML parser. Very
slow but was easy to download and implement. Since then I have found
and installed service program for XML parsing that is written in C and
very easy to use. It runs circles around the JAVA version as far as
the way our application runs to parse a single XML file or create a
single XML file. We even have it in our transaction parsing program
where our web servers pass the unformatted data back to the iSeries for processing.
I guess there is a place for JAVA, just not the way we are using it.
Chris Bipes
Director of Information Services
CrossCheck, Inc.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
