Re: zAAP vs x64 performance comparison
1) zAAPs were only doing Java work. The z10 machines at the time had no option for zAAP on zIIP, so we're talking about real zAAPs here, which only are eligible for Java work. 2) Yes, when I said zAAP-eligible I meant just JVM work, not including stuff that isn't eligible. For example, if you look at the Websphere address spaces, the servants running the application Java code are almost all eligible. But the daemon, node agent and server all do more work that's not eligible. If you look in SDSF, there are a few data columns of interest: JOBNAME CPU-Time GCP-Time zAAP-NTime zACP-Time zAAP-Time ECPU-Time P3SR01AS 2189.2022.082039.81 6.72328.213225.14 P3SR02AS 7197.2465.006995.91 13.61 1125.679299.76 P3SR02A 1303.91 663.30 582.25 0.78 93.681303.91 P3SR02BS 7536.5365.277314.36 12.95 1176.919854.92 P3SR01A 516.91 106.61 381.86 1.47 61.44 516.91 P3SR01BS 1997.0914.321849.42 5.75297.582086.93 P3DMGR 5358.58 656.194511.57 30.37725.935358.58 P3SR02B 1314.07 649.79 603.67 0.92 97.131314.07 P3AGNTA 3111.00 418.392495.72 8.96401.573111.00 CPU-Time is the total normalized time across all the processor types. IIRC, ECPU-Time includes some enclave time that CPU-Time does not. GCP-Time shows the time on the GCPs. zAAP-NTime, is the zAAP time, normalized to the GCP speed, whereas the zAAP-Time column shows the non-normalized values. (Since those are different above, you can see I'm running on sub-capacity GCPs and the normalization factor is about 6.2x.) zACP-Time is the time on the GCP that was zAAP-eligible but for some reason ran on the GCP. You can see that 's very tiny. It will never be zero because of the way some interrupts are handled, but with IFAHONORPRIORITY=NO it can be very small. Note that NO is not appropriate in all situations. So when I said 95% of their zAAP-eligible time is on the zAAPs, I meant zACP / (zACP+zAAP-N). Here's an example though where it works out to 94% though: JOBNAMECPU-Time GCP-Time zAAP-NTime zACP-Time zAAP-Time ECPU-Time RTMSERVE 14639.67 7958.276564.75421.45 1056.30 14639.67 RTMSERVE3708.42 275.123392.55 8.20545.883708.42 That first address space spends a fair amount of time calling REXX scripts from the JVM, so there's more swapping backs and forth between the GCP and zAAP, and that's probably got something to do with why it has more zACP time. You'll also notice that ECPU-time = CPU-Time in this example, supporting my recollection that ECPU-time has something to do with the enclave time as there's no enclaves involved here. All this data is also in the type 30 SMF records. I'm glad you found the post interesting. Scott On Thu, 28 Aug 2014 08:24:59 -0500, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: the z10 zAAPs stayed at right around 15-20% busy or so. With or without, for example, DB2 work offloaded to zAAP? With that set to no I think all of my JVMs show 95% of their zAAP-eligible time is on the zAAPs, and 98% is not uncommon. Just curious and if you don't mind please, what did you used to measure those usage percentage? Are only the JVM work measured or not? I don't think I answered your question, but hopefully I've given you some things to think about. But you gave a good general answer. I believe many on IBM-MAIN can learn from it. Many thanks! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zAAP vs x64 performance comparison
In short, in my experience, Java performance on the mainframe is acceptable to very good today. If you're trying to make the case that my mainframe processor is faster than your processor in your laptop, that's somewhat difficult to prove because the processors and systems are designed for different use cases: high throughput for large mutli-user workloads vs. high performance for single-user workloads. I believe you could construct a benchmark that would prove either platform is superior. If you're trying to get a feel for is Java fast enough on the mainframe, then the answer is generally yes, it Java on the mainframe with adequate zAAP capacity is more than likely fast enough. I have Java workloads I've run on both Intel and zAAPs and the difference in performance (on the last few generations of z hardware, with adequate zAAP capacity) is not generally significant. I/O performance can be a much more interesting component than the CPU time. If you're trying to determine how much zAAP capacity you're going to need to run a particular workload on the mainframe, that's more complicated. Your best bet is to actually test the workload there. Again with adequate zAAP capacity, or on an off time with adequate GCP capacity. If testing on GCPs, take care if you're using sub-capacity GCPs. Several years ago we did a test for a relatively large (for us) Websphere application on both AIX and z/OS. The proposed AIX config was something like a pair of 16-way AIX boxes. The z config was 4 z9 zAAPs (two on two separate CECs). Personally, I think the AIX boxes were likely over-configured, but I wasn't responsible for testing on that platform, so I can't say for sure if that was the case. In the end the application ended up going live on 6 z10 zAAPs, and the z10 zAAPs stayed at right around 15-20% busy or so. Note I say zAAP, but zAAP on zIIP should be effectively the same. Other than of course you may have more workloads competing for those zIIPs. Note that depending on the xxxHONORPRIORITY setting in IEAOPTxx, Java workload may fall back to GCPs. Depending on how many specialty engines you have, how busy your GCPs are, and whether or not you're running sub-cap GCPs, you may want to consider setting xxxHONORPRIORITY=NO to keep as much of the Java work on the specialty engines as possible. With that set to no I think all of my JVMs show 95% of their zAAP-eligible time is on the zAAPs, and 98% is not uncommon. If you're trying to test the same code on both platforms be aware that there are a lot of differences to worry about... You probably are not running the same JVM on Windows as you are on z/OS. JVM settings such as heap size and the garbage collection algorithm can make for significant differences in run times. If you're running relatively short-lived tests, the JVMs may not JIT the code in the same timeframe on both platforms. The I/O subsystems as well as the file systems are completely different between the platforms. If the application uses JDBC, the performance of the database, and of the network between the JVM and the database can easily be the most important component. I don't think I answered your question, but hopefully I've given you some things to think about. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zAAP vs x64 performance comparison
Scott Chapman wrote: I believe you could construct a benchmark that would prove either platform is superior. True. Some vendors are building benchmark to 'prove' their own hardware and/or software is 'better'. I/O performance can be a much more interesting component than the CPU time. Of course. That (I/O Performance) and type of workload mix can throw up any benchmarks you're trying to use. the z10 zAAPs stayed at right around 15-20% busy or so. With or without, for example, DB2 work offloaded to zAAP? With that set to no I think all of my JVMs show 95% of their zAAP-eligible time is on the zAAPs, and 98% is not uncommon. Just curious and if you don't mind please, what did you used to measure those usage percentage? Are only the JVM work measured or not? I don't think I answered your question, but hopefully I've given you some things to think about. But you gave a good general answer. I believe many on IBM-MAIN can learn from it. Many thanks! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
