Relating Production Workloads to LSPR Workloads

A wide variety of DP workload environments exist throughout the world, using any number of different software products. It is highly unlikely that an individual LSPR workload will represent the totality of a particular production workload. Rather, the LSPR workloads are intended to define the envelope (or range) of the expected capacity difference between two processors. As part of a capacity planning exercise for a particular production workload, the intent should be to estimate where in the envelope the production workload will fall by considering a mixture of the LSPR workloads that best represent the production environment.

LSPR Default Mixed Workload

Historically, the LSPR has defined a “default” mixed workload capacity ratio which is made up of the harmonic mean from an equal weighting of the component workloads. The default mixed workload for the z/OS 1.8 LSPR is made up of four workloads: OLTP-T, OLTP-W, WASDB, and CB-L. The formula for determining the relative capacity for a mixed workload is given below and is based on a "harmonic mean" calculation.

[8]  ITR Ratio for Mixed workload = 1 / ((WK1 % / WK1 ITRR) + ... + (WKN % / WKN ITRR))

Table 4 provides an example of the LSPR default mixed workload ITR ratio based on a 2094-716, thus individual workload ratios have been scaled to 1.00 for the 2094-716. The mixed workload ITRR are computed using formula 8 above.

While the LSPR default mixed workload does include a broad range of applications, it does not necessarily correctly position a particular production workload within the capacity envelope. A more accurate use of the LSPR for capacity planning involves “tailoring” a mix of the LSPR workloads to match a production workload.

Tailoring the LSPR workload mix to match a production workload

When is tailoring a workload mix necessary? The answer is when the LSPR capacity ratios for a particular upgrade path indicate a wide variation among the workloads. There are many historical examples of this situation. Workloads will react differently based on what was changed in the processor design (for example: cycle time, high speed buffer structure, paths to memory). When considering a particular upgrade, the LSPR capacity ratios for each workload type should be examined. If all the ratios are similar, using the LSPR default mixed workload ratio should provide an accurate estimate of expected capacity. However, if there is a large variation in workload performance, it is very important to use a workload mix tailored to the production environment in question.

How to tailor a mixed workload

For workloads that have been reasonably stable over a period of time, and whose actual capacity ratios have been carefully tracked across previous upgrades (and compared to the LSPR workload capacity ratios), the appropriate mix of LSPR workloads may have already been proven to yield accurate estimates (although this must be reexamined in light of any new LSPR workloads). Note this tracking must have been based on detailed before/after analysis - do not be lulled into a false sense of security by comments such as “We got what we expected” or “We’re happy because it’s better than expected” - the latter should actually be a warning sign that the proper mix has not yet been identified. For workloads with less history, or less scrutiny of past upgrade performance, the following guidelines are provided.

Online to “other” ratio

The first step is to split the production workload into two major categories: online and “other.” The online component is defined as the portion of the workload involved in transaction processing where the end user typically is sitting waiting for a response. Examples would include TSO, IMS, CICS and Web Sphere workloads. Note that some parts of workloads with these labels are actually more batch-like and should not be included in the online component. For example, IMS BMPs and DB2 complex queries are typically batch or batch-like and thus should not be included as online work. The “other” component basically is a catchall for everything else. Batch, system, started tasks, and monitors are examples for this component, but actually, it is simply everything that is not classified as online. At the end of this step, an online-to-other ratio will have been identified, such as 60% online and 40% other.

Tailoring the online component

Once the online component of a production workload has been identified, a mix of the three LSPR online workloads, OLPT-T, OLTP-W, and WASDB must be chosen. One approach would be a simple "middle of the envelope" mix of equal portions of each workload. As an example, if the online component is 60%, one could simply divide this percentage equally among the workloads yielding 20% of each of OLTP-T, OLTP-W and WASDB. It might be reasonable to adjust the mix in proportion to the type of online workload (such as 40% traditional OLTP and 20% web-enabled OLTP, still summing to 60%). Some judgment is necessary to relate how much of each of the LSPR online workloads (traditional OLTP, web enabled OLTP and Web Sphere application serving) is required to approximate a particular production environment. Finally, if the overall system being evaluated has a low DASD IO content, a higher portion of the lower-IO rate online workloads, WASDB and/or OLTP-W, should be used. If the total system DASD IO per second per MSU (that is, the total DASD IO rate divided by the used MSUs of the system) is less than 30, this indicates the need to significantly increase the proportion of WASDB and/or OLTP-W to represent the "Online" component. (Note: when performing this calculation for workloads running on z990s or z890s, the resulting DASD IO per second per MSU must be multiplied by 0.9 to adjust for the fact that the MSU ratings for these processors have been set below their actual capacities to provide for improved software price/performance . Likewise, for workloads running on z9-109, a multiplier of 0.81 should be used, and for workloads running on a z10 EC a multiplier of 0.73 should be used for the same reason).

Tailoring the other component

For the "other" component, a mix of the batch workloads, CB-S (in the z/OS V1R4 table), CB-J (in the z/OS V1R6 tables) and CB-L (in all tables), should be chosen. One could be tempted to choose equal portions of each, however, note, that the characteristics of CB-S, CB-J, and CB-L can be significantly different, thus, there is more reason to deviate from using an equal mix. CB-S may be qualitatively characterized as many short batch job steps with a fair amount of I/O, while CB-L has much longer and heavier CPU-consuming jobs. CB-J is a heavy exploiter of Java. Production batch often leans toward CB-L more so than CB-S, so skewing the other component toward CB-L is appropriate. Another indication of a more CB-L-like workload is a low DASD IO content for the overall system. If the total system DASD IO per second per MSU (that is, the total DASD IO rate divided by the used MSUs of the system) is less than 30, this indicates the need to significantly increase the proportion of CB-L in relation to CB-S, potentially using only CB-L to represent the other component. (Note: when performing this calculation for workloads running on z990s or z890s, the resulting DASD IO per second per MSU must be multiplied by 0.9 to adjust for the fact that the MSU ratings for these processors have been set below their actual capacities to provide for improved software price/performance. Likewise, for workloads running on z9-109, a multiplier of 0.81 should be used, and for workloads running on a z10 EC a multiplier of 0.73 should be used for the same reason).

Tailored Workload Mix Example: The LoIO Mix

Many production workloads exhibit the low DASD IO characteristic described above, that is, they have a total system DASD IO per second per MSU less than 30. Here we describe a tailored, or customized, mix of LSPR workloads known as the "LoIO Mix" that is often used for this situation in the IBM capacity planning tools. From updated studies of numerous production workloads, the average split of the "online" and "other" components is 56% online and 44% other. To represent the online component, we use the two LSPR online workloads with lower IO content. Thus, the online component is represented by 28% WASDB and 28% OLTP-W. To represent the other component, we use the one LSPR commercial batch workload with lower IO content. Thus, the other component is represented by 44% CB-L.

Table 5 provides an example of using the customized “LoIO Mix” of LSPR workloads based on a 2094-716, thus individual workload ratios have been scaled to 1.00 for the 2094-716. The LoIO mix workload ITRRs are computed using formula 8, above.

Tailored Workload Mix Example: The TI Mix

Another customized mix used in the IBM capacity planning tools is referred to as the Transaction Intensive or TI Mix. This tailored mix of LSPR workloads is intended to represent a very heavy online workload and is often used when 1) the online component of a production workload is high and 2) the DASD IO content of the production workload is high (greater than 30 DASD IOs per second per MSU). For the z/OS V1R8 table, the workload components weights are set to: 40% OLTP-T, 40% OLTP-W and 20% CB-L.

Tailoring a mix of LSPR workloads to match a production workload is not a purely scientific exercise, applying some judgment is unavoidable. The intent is to provide a reasonable capacity estimate for an upgrade path. The best indicator of an accurate mix is a carefully analyzed track record of past upgrades. For those who want to be conservative in their estimates, several tailored mixes may be tried and the mix producing the more conservative estimate may be chosen.

Tracking to a Tailored Workload Mix

A customized mix of LSPR workloads is comprised of individual workloads that may have different capacity ratios and are combined into a mixed workload ratio using the harmonic mean calculation. Workloads that run independently will to track to their individual ratios. However, once workloads are mixed together, then they are somewhat influenced by the type of work they are mixed with and they tend to "center" on each other. Thus, for tracking purposes, one might expect individual production workloads to track closer to the estimated customized mix ratio than individual component ratios.