Re: Java 1.6 batch performance issue

Does the java job get the info from the remote in one go up front and then
process the data locally or does it revisit the remote many times? Either
way the overrun may caused by a number of factors on and off the IBM i
including network latency or even enhanced data volume. Although unusual,
an overrun of 50% may not be excessive - depending on circumstances and
ideally the job scheduling software should be able to accommodate this.
Something like Robot Scheduler with its inter-job dependencies would be
useful, eg. job B doesn't start until job A completes.

Also if you have access to the java code then you could include a fairly
simple logging utility to output timestamps at strategic points during the
overall java process. log4j is good as it's flexible via configuration with
minimal performance impact.

On 20 February 2016 at 14:49, DrFranken <midrange@xxxxxxxxxxxx> wrote:

I'm not a java guy unless it's in my coffee cup, HOWEVER I saw the words
"remote System" in there. So being the IBM i Guy, I'd blame the network..
:-)

OK Perhaps blame is a strong word but I would verify that DNS is working
switftly that communications isn't bottled up and that the far system is
having no performance issues.

I have one customer at the moment with some Java task running that is
querying global DNS for the FQDN of the IBM i partition. It is doing this
even though the name is in the local hosts table AND lookups are set to
*LOCAL first. Not a big deal until you see that it's doing this nearly
500,000 times per day and that's slowing it down.


- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.


On 2/20/2016 3:49 AM, MARK GOLDEN wrote:

Hi ,
You could use WRKJMVJOB command which offers various options.You can use
option 5 from the WRKJMVJOB screen and then option 50. Display job.Find and
display Garbage collection (GC) timings which can sometimes indicate a
problem.
R,Mark.

On Saturday, 20 February 2016, 3:35, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:


It could be possible other jobs were slowing down the systems so
therefore the java would also run slow.

If your team wrote the java code, possibly add some logging logic to the
app perhaps and viola - joblog ?

All things being equal it was probably some other job or jobs slowing
things down if this job has been consistent.

Also on the scheduling front you may want to put something in place to
flag completion of the java job before other jobs kick off.

Of course HelpSystems has options for scheduling and system monitoring,
but minimally I would re-consider simply time based kickoffs.

Regards,

Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
Visit me on: Twitter | LinkedIn
------------------------------

message: 6
date: Fri, 19 Feb 2016 21:32:13 +0000
from: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
subject: Java 1.6 batch performance issue

We have a batch job that uses Java 1.6 get info from a remote server.
Normally the process takes 1 1/2 hours.
This morning it took 2 hours 15 minutes, 45 minutes longer.
Other processes were dependent on the timely completion of this info.
Because its Java, joblog does not help.
What tools can be used to troubleshoot/isolate this issue?
Anything in MPG?

8205-E6C 740
1.5 CPU
155gb mem
100% SSD
V7R1 Latest CUM, TR11, most latest groups
Java Group 23

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/


--

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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.