We have a TomCat webapp that runs very fast when run on any box EXCEPT under USS. When run on Windows, Linix, Solaris, you name it, it is fine.
Under USS, JVM 1.4.x, it runs EXTREMELY slow and comsumes a fair amount of CPU. There is a fair amount of java code - 800,000 lines or so, so I know that the JIT is working his tail off at startup, but it seems to not smooth out even after most code is likely to have been compiled (i.e., JIT'd).
In general terms, will JZOS improve performace, since the webapp will no longer be running under USS?
JZOS vs USS performance
JZOS uses the same JVM as the USS shell, Websphere, CICS, etc. The performance of running an application under JZOS will, in general, match that of running under a USS Shell. This might not be true in specific cases where there is something wrong with the USS shell environment configuration (that differs from the JZOS batch address space). Its very easy to give JZOS a try to see if there is a difference. If so, then the difference will be due to tuning / settings of the USS shell environment.
What hardware platform are you running z/OS on? If you are running on a FLEX/ES emulator, then you will find that the JVM runs very poorly.
The z/OS JVM is not particularly fast when it comes to raw computation, but Java applications that exploit z/OS's great I/O throughput can run very well on z/OS.
It could be that there is a "tuning" problem with your JVM or z/OS system. The following links may be of help when tuning the z/OS Java runtime environment:
http://www-1.ibm.com/servers/eserver/zs ... vafaq.html
ftp://www6.software.ibm.com/software/de ... iag142.pdf
ftp://www6.software.ibm.com/software/de ... 042005.pdf
http://www.phptr.com/articles/article.a ... Num=6&rl=1
It is often helpful to do some performance profiling to figure out which part of your application is slow. The Eclipse TPTP project has a free profiling tool for z/OS:
http://www.eclipse.org/tptp/index.html
What hardware platform are you running z/OS on? If you are running on a FLEX/ES emulator, then you will find that the JVM runs very poorly.
The z/OS JVM is not particularly fast when it comes to raw computation, but Java applications that exploit z/OS's great I/O throughput can run very well on z/OS.
It could be that there is a "tuning" problem with your JVM or z/OS system. The following links may be of help when tuning the z/OS Java runtime environment:
http://www-1.ibm.com/servers/eserver/zs ... vafaq.html
ftp://www6.software.ibm.com/software/de ... iag142.pdf
ftp://www6.software.ibm.com/software/de ... 042005.pdf
http://www.phptr.com/articles/article.a ... Num=6&rl=1
It is often helpful to do some performance profiling to figure out which part of your application is slow. The Eclipse TPTP project has a free profiling tool for z/OS:
http://www.eclipse.org/tptp/index.html
-
Guest
We had done some stresstests via jmeter, intel-xp , z990 suse zlinux and z990 z/os. Currently it looks like that zlinux will perform better than z/os but we have to verify the network path again.
Server startup is always slower on z990 than intel, but hfs isn't a very good filesystem and zfs isn't stable.
Server startup is always slower on z990 than intel, but hfs isn't a very good filesystem and zfs isn't stable.
-
Guest
I am curious about why you made the statement that zFS is not stable.
I can tell you that I was having various response time problems with general USS tasks.. the fix was security related. It had to do with sharing a security file in the coupling facility and the amount of time each system waited when there was a lock contention.
I can tell you that I was having various response time problems with general USS tasks.. the fix was security related. It had to do with sharing a security file in the coupling facility and the amount of time each system waited when there was a lock contention.
Follow up.
We have not yet run JZOS.
TPTP helped a great deal. We were doing a fair amount of disk I/O that would not have been releaved without the use of TPTP. We also had some inefficient code. TPTP is somewhat of a hog for us in z/OS, so I was able to identify most of the performance bottlenecks on the PC first and we saw the performance enhancements carry over to z/OS.
We documented a 14% performance gain JUST by switchiing to ZFS -- no other change required.
Our overall performance gain under z/OS was 48.38%.
We had a strict testing regiment. An important part of which was starting Tomcat with the -Xcomp option set (e.g.: export TOMCAT_OPTS="-Xms96M -Xmx160M -Xcomp"). This option caused all JITing to occur on the first encounter of a method instead of the default method counting scheme. We don't run the product with the -Xcomp set by default, as it REALLY slows down initial startup.
To test, we would start the server, do consistent UI interaction during server startup, and then let the server run for 30 minutes. This 30 minute wait allowed all compiling to complete. We then performed consistent UI interaction for a specific amount of time and recorded the CPU usage as reported by the SDSF PROCESS DISPLAY (=m.5.PS).
-Xcomp was very important for measuring performance because we found that many of our initial tests were invalid. Why? Beacause we found that we were benchmarking java compile time, and not application execution time.
We have not yet run JZOS.
TPTP helped a great deal. We were doing a fair amount of disk I/O that would not have been releaved without the use of TPTP. We also had some inefficient code. TPTP is somewhat of a hog for us in z/OS, so I was able to identify most of the performance bottlenecks on the PC first and we saw the performance enhancements carry over to z/OS.
We documented a 14% performance gain JUST by switchiing to ZFS -- no other change required.
Our overall performance gain under z/OS was 48.38%.
We had a strict testing regiment. An important part of which was starting Tomcat with the -Xcomp option set (e.g.: export TOMCAT_OPTS="-Xms96M -Xmx160M -Xcomp"). This option caused all JITing to occur on the first encounter of a method instead of the default method counting scheme. We don't run the product with the -Xcomp set by default, as it REALLY slows down initial startup.
To test, we would start the server, do consistent UI interaction during server startup, and then let the server run for 30 minutes. This 30 minute wait allowed all compiling to complete. We then performed consistent UI interaction for a specific amount of time and recorded the CPU usage as reported by the SDSF PROCESS DISPLAY (=m.5.PS).
-Xcomp was very important for measuring performance because we found that many of our initial tests were invalid. Why? Beacause we found that we were benchmarking java compile time, and not application execution time.
Java startup time on z/OS is a well recognized problem, and every new SDK version makes it worse 
If you look at the Sun documentation for Java 5, you will see that there is a facility called "Class Data Sharing":
http://java.sun.com/j2se/1.5.0/docs/rel ... sdatashare
Essentially, it allows for pre-JITed classes to be stored in a shared memory segment that is shared by all Java process on the system. The initial Sun release only allows for sharing of the JRE classes (rt.jar, etc), but it is designed to allow for application defined shared class caches (like all of Tomcat maybe?)
If ever such a facility comes to z/OS Java, it might really help... (especially for short-running batch jobs, which are impractical today).
If you look at the Sun documentation for Java 5, you will see that there is a facility called "Class Data Sharing":
http://java.sun.com/j2se/1.5.0/docs/rel ... sdatashare
Essentially, it allows for pre-JITed classes to be stored in a shared memory segment that is shared by all Java process on the system. The initial Sun release only allows for sharing of the JRE classes (rt.jar, etc), but it is designed to allow for application defined shared class caches (like all of Tomcat maybe?)
If ever such a facility comes to z/OS Java, it might really help... (especially for short-running batch jobs, which are impractical today).
-
Guest
IBM Java 1.5
You can test and keep up with where IBM is with 1.5 at:
http://www-128.ibm.com/developerworks/j ... java5beta/
http://www-128.ibm.com/developerworks/j ... java5beta/
Have any specific reasons for poor performance under FLEX/ES ever been identified e.g. poor emulation of certain instructions, absence of certain performance assists, etc...?
dovetail wrote:JZOS uses the same JVM as the USS shell, Websphere, CICS, etc. The performance of running an application under JZOS will, in general, match that of running under a USS Shell. This might not be true in specific cases where there is something wrong with the USS shell environment configuration (that differs from the JZOS batch address space). Its very easy to give JZOS a try to see if there is a difference. If so, then the difference will be due to tuning / settings of the USS shell environment.
What hardware platform are you running z/OS on? If you are running on a FLEX/ES emulator, then you will find that the JVM runs very poorly.
The z/OS JVM is not particularly fast when it comes to raw computation, but Java applications that exploit z/OS's great I/O throughput can run very well on z/OS.
It could be that there is a "tuning" problem with your JVM or z/OS system. The following links may be of help when tuning the z/OS Java runtime environment:
http://www-1.ibm.com/servers/eserver/zs ... vafaq.html
ftp://www6.software.ibm.com/software/de ... iag142.pdf
ftp://www6.software.ibm.com/software/de ... 042005.pdf
http://www.phptr.com/articles/article.a ... Num=6&rl=1
It is often helpful to do some performance profiling to figure out which part of your application is slow. The Eclipse TPTP project has a free profiling tool for z/OS:
http://www.eclipse.org/tptp/index.html