× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thorbjoern Ravn Andersen wrote:
Pete Hall skrev:
Yes, it's the initial request that causes the biggest hit (by far.) I'm
more concerned about the impact of multiple requests in production.


First of all, which JVM do you use? The Classic or the Technology one?
I'm using the classic JVM 1.6

Based on advice I've gotten on this list, I have concluded the following:

* The Classic JVM takes ages to pull up and you need to help it all you
can by preserving jar and class files unmodified in the IFS. (The
exploded wars e.g.).
* The default behaviour of OS/400 is to aggressively swap out memory
used by JVM's (as they are large), which doesn't work well with the Java
Garbage Collector which want's the whole heap in memory. It appears the
typical advice is a separate storage pool.
Ok. I will experiment with that.

* The default garbage collection values for the Classic JVM are too
small for non-trivial Java programs, and they do not automatically
adjust. It requires experiments in the scenario it is to run to get the
value right.
Hmmm. I didn't realize I could control that. More reading...

* Given enough space to avoid swapping, and given enough time to settle
after startup, I've found the Classic JVM to have acceptable performance
comparable to a PC, but it really takes time to get there.
That's ok. I can script the startup so that it loads the java classes

If you run under the Classic JVM, I would suggest you enable garbage
connection logging to QPRINT (-verbosegc or OPTION(*VERBOSEGC) I belive)
so you can get an idea of what goes on. The BIRT reports probably takes
a LOT of memory so a lot of aggresive garbage collections probably happens.
Ok. Good tip. Thanks

Tomcat 6 extracts the contents of the war file already. I removed the
war files from the webapps directory. That didn't seem to make a
difference.

No. It is the unpacked version that Tomcat uses.
I don't understand. Are you saying that I need to do something other
than removing the .war's?

By the way, we found that the QSH command "du" includes the hidden data
produced by the JVM. You can use that to get an idea of the amount of
work done by comparing to the size of your own files.
Also good advice. Thanks Thorbjoern.

- --
Pete Hall
pete@xxxxxxxxxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktVGwIACgkQXczQcKdXKg53QQCeOTzuJVvuC6aIx1DHfGaD0aJc
+RMAoJpLBuV8g7Ke+3CNT9W6myxct3vi
=nogr
-----END PGP SIGNATURE-----

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.