One of the most common methods for measuring z/TPF system performance is to use the “Milliseconds Per Weighted Message” value that is included in a z/TPF Data Reduction Report. This value represents the average number of milliseconds (mills) of CPU time that are consumed for each message that passes through the z/TPF system. The metric is calculated by taking the TPF AVERAGE CPU UTILZATION, dividing it by the WEIGHTED MESSAGE RATE and then multiplying it by the NUMBER OF I-STREAMS IN USE. The result of this equation is the raw number of seconds per message. In order to project Milliseconds per Weighted Message, this result is multiplied by 1,000. As an example, consider a system with the following characteristics:
- Average utilization is 75.8%, or .758 for the purposes of these calculations.
- Weighted message rate is 5432 messages per second.
- There are 9 I-streams in use.
Mills per weighted message is then: .758/5432 * 9 * 1000 which equals 1.25589 and would be displayed as 1.256 in the Data Reduction Report.
Seems simple enough: if application path length increases, then the mills per message goes up. If a more efficient algorithm is used, then the mills per message goes down. This value can be useful to analyze performance as a result of system configuration changes—for example, the addition or removal of I-streams or the migration to a new processor with a different number of I-streams than the original environment.
To assist with this evaluation, the z/TPF Lab publishes the Internal Throughput Rate Ratio tables, which are commonly referred to as the ITRRs. These values represent the relative power of the processor based on the processor family and model type. Locating the ITRR rating of the current processor will help identify what processor family and model type should be planned for to accommodate processing needs. For example, if your current processor is a z14-709 with an ITRR rating of 450.4 and you wanted to add an additional 30% capacity, then you would look for a model in the table that had an ITRR rating of at least 585.5. This could be accomplished with either a z14-713 with an ITRR rating of 606.9 or a z15-711 with an ITRR of 594.6.
It is very important at this point to note that the ITRR projections are to be used for planning purposes only and are not a guarantee of processor performance. There are many factors involved in how the processor responds to a specific workload, so the ITRRs provide a starting point for estimating processor capacity. The latest version of the ITRRs should always be used when sizing a replacement processor and can be obtained by sending a request to TPFQA@us.ibm.com.
Evaluating the performance of a new processor starts with a baseline metric of the existing processor. There are a variety of ways to do this, and one is to use the mills per message value from data reduction. As all environments have some level of variability, it’s best to establish an average over a period of several days or weeks with a workload that is representative of the system. Take note of trends that align with days of the week or time of day, as it will be important later when attempting to compare results on the new processor.
Once the baseline is established, the next task is to collect measurements on the proposed environment. Ideally, these measurements are gathered in a test configuration that closely matches what will be running in production, however, this is not always possible. In some scenarios, the measurements cannot be performed until after the migration to the new processor is complete. As with the baseline measurements, it is important to gather data across multiple days or weeks. Comparisons must also be made to similar days of the week or times of day if trends were observed when collecting the baseline data.
After collecting all these measurements, the question remains as to whether the performance of the new processor has met the expectations as defined by the ITRRs. Determining this by comparing the mills per message between the old and new configurations requires an understanding of the relationship between the ITRR and mills per message values. Fundamentally, the mills per message will go down if the power per I-stream in the new configuration is greater than the current setup, and it will go up if the power per I-stream went down.
The difficulty in this approach is that the ITRR values represent the capacity of the entire processor, not an individual I-stream. The capacity of each I-stream can be calculated by dividing the ITRR value by the number of engines on the processor. For example, returning to the z14-709 example, which has 9 I-streams and an ITRR value of 450.4, the relative capacity per I-stream is 450.4/9, equaling 50.04.
The capacity per I-stream values from the old and new configurations can be used to determine the projected mills per message value based on the baseline measurement. Multiplying the baseline mills per message times the ratio of the old I-stream capacity to the new will yield the projected mills per message with the new processor.
Using the z14-709 example, and recalling our objective of a 30% capacity improvement, we can look at how the mills per message would change by going to either the z14-713 or the z15-711.
If the selected processor was the z14-713 with an ITRR value of 606.9, then the capacity per I-stream would be 46.68. We have already calculated the capacity per I-stream of the z14-709 as 50.04, and for the sample workload the mills per message was 1.256. Therefore, the projected mills per message following the migration would be 50.04/46.48 * 1.256 which equals 1.346. In this case, moving to a more powerful processor would result in an increase of mills per message because each I-stream has a slightly lower capacity. This minor degradation is a result of the Multi-Processor (MP) effect as additional I-streams increase the contention for shared resources within the processor.
If instead the selected processor was the z15-711 with an ITRR value of 594.6, then the capacity per I-stream would be 54.05. The baseline mills per message are still the same, 1.256. Therefore, the projected mills per message following the migration would be 50.04/54.05 * 1.256 which equals 1.163. Here, we can see that because each I-stream is more powerful, we would project a decrease in mills per message.
It’s worth noting again that the ITRR projections are intended to be guidelines and are not guaranteed results. Differences from one customer environment to another and even differences between workloads within the same customer will yield different results. The ITRRs provide a starting point, and using them in conjunction with milliseconds per message can deliver a metric to evaluate the performance of a new configuration.