This chapter is from the book
This chapter is from the book
This chapter is from the book
23.1 Overview
The purpose of this chapter is to assist you in tuning the performance of WebSphere V5 on your z/OS system. The general focus will be on z/OS-specific items, as the previous chapter discussed more general information. We mention tuning here as performance is not something to be considered only as an afterthought or when the application is perceived as not performing well (performance problem). These are certainly times when performance does need more focus, but performance should be considered from the earliest stages of any product life cycle.
z/Linux performance considerations are covered in Appendix H (z/Linux).
23.1.1 Problem versus Perception and z/OS Resources
When someone perceives and reports a performance problem, it is important to understand the basis of the performance expectations relative to the application and the resources devoted to it. Applications running in a J2EE environment tend to take more resources (specifically memory and CPU) than typical legacy applications running on z/OS. If all tuning has been done correctly, it may be that the application simply requires more resources than were previously estimated. This often happens when the application is modified and becomes more complex than originally intended. You must also understand the z/OS resources "assigned" to your application.
It is beyond the scope of this document to discuss the cycle times or processor power of the z/Series hardware configurations, but there are some important things to note:
z/OS CPU resources tend to be shared. That is, your image/Logical Partition (LPAR) is usually given some share or percentage of the total CPU resources available. This gets complicated further when you consider that LPARs can take advantage of unused cycles from other LPARs if they have shared CPUs and are not capped. A good Resource Management Facility (RMF) report can yield much information on this.
Your z/OS LPAR or image will often be running WebSphere and one or more subsystems (DB2, CICS, IMS, etc.). Thus, a direct comparison between WebSphere on the distributed platforms using these back-ends and WebSphere on z/OS using them must account for the extra CPU cycles used by the back-end system itself.
z/OS systems generally run a mixed workload and are not dedicated to WebSphere applications as are servers on distributed platforms. This makes it more important to understand the impact that WebSphere is having on the other workloads and not just the overall system performance.
The importance of having sufficient memory (discussed later along with paging) for the workload on the system cannot be overstated. There is little marginal cost for memory and having insufficient memory can cause paging, which degrades performance.
A common issue with z/OS resources occurs when someone tests an application on their workstation (e.g., a uniprocessor 2.4 GHz machine) and then moves it up to z/OS (the "big" box). z/OS images for test or development are often given a very small share of a full z/OS machine. We have seen images running as little as 150 MHz. Thus, instead of achieving a great performance boost by moving to z/OS, performance actually degrades.
WebSphere z/OS, in nearly all cases, achieves equivalent performance to WebSphere on the distributed platforms when comparing the same amount of CPU resource. On the other hand, z/OS hardware tends to be more expensive than distributed platforms. The extra cost of z/OS hardware is offset by its qualities of service (QOS) which are superior to other platforms. It is generally a balancing act between QOS and cost as to how an application is deployed. This discussion is beyond the scope of this chapter.