James,
What you describe sounds like an I/O bottleneck. With the performance tools
(even as far back as V5R4) you should be able to see what the major wait
states are and based on what your describing I'll bet on I/O queuing. Are
the DASD controllers higher end with cache? What's the Cache hit rate?
The other thing to look at is the IFS. (since that's all IFS work and Java
is a major dog for performance) Is the root loaded up with too many
objects/directories? Are the Path variables set to avoid the scanning of
large directories with many subdirectories to look for the TomCat (Catalina
if I remember correctly) files?
Just some thoughts, but the performance tools should help you identify the
bottleneck.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: JAVA400-L [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James
H. H. Lampert
Sent: Wednesday, November 02, 2016 3:25 PM
To: Java 400 List
Subject: Tomcat deploy/undeploy speeds
Fellow midrange geeks:
We have a number of customers for which we are managing Tomcat servers on
their own Midrange boxes (to run the web extension of our CRM product).
Differences in context deployment speeds is of course, in part, a function
of how long it takes to get a 101M WAR file onto their machine.
But that wouldn't be a factor in undeployment, nor in starting or stopping a
context.
And we're finding wide variations in those speeds: sometimes, a matter of
seconds, and sometimes you could go out and get coffee -- at the Starbuck's
around the corner -- and find that it's still processing.
Sometimes, we'll see variations this extreme on boxes that are at least
theoretically the same model. We've put Tomcat into its own subsystem, with
its own private pool, and "throw memory at it," with little or no
improvement in speed, and sometimes, we've seen boxes that look tiny and
underpowered give quicker responses than big heavy-duty models.
Anybody have any suggestions we haven't already tried?
--
JHHL
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing
list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
