This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
TrueSight Capacity Optimization
TrueSight Capacity Optimization 11.0, 10.7, 10.5, 10.3
We are looking to import Response Time metrics into TSCO via the TSCO Gateway Server VIS parser ETL. What configuration on the TSCO Gateway Server Manager side is required to import response time metrics?
Response Times in TSCO come from having the Predict component enabled in the nightly Manager runs.
The typical configuration recommendation is to disabled Predict because the nightly Manager runs becase (a) Predict, in general, significantly increasing the nightly Manager run times and (b) There is an issue (fixed in the latest TSCO Cumlative Hot Fix packages) where the Hardware Table read (which Predict does once per interval per domain per Manager) takes a very long time to complete due to an excessive number of account lookup calls.
If one wanted to enable Predict it would be best to do the following:
(1) Make sure that you are running the CHF level or better described in this following KA:
000139363: TSCO Gateway Server Manager runs with Predict enabled are running very, very slowly on the Linux console (https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000139363)
(2) Start off by testing how much the addition of Predict to a test Manager run increases the processing duration of that run. But it can require a lot more TSCO Gateway Server console hardware to support Predict being enabled in an environment (depending on your current and maximum processing window length).
One of the big issues with Predict is the number of hardware table reads that are required in the nightly Manager run. Analyze on Linux (although not on Windows) is able to read the hardware table once and then use it for all intervals in the domain being processed. But Predict is executed as a separate process for each interval. So, for 15 minute granularity you end up with 96 executions of Predict and if the XML hardware table read takes 11 seconds (which isn't out of the ordinary) that is over 15 minutes of elapsed time just reading the hardware table.
Q: For most customers is there a benefit to enabling Predict for response time calculation reporting into TSCO?This is purely an opinion but although Response Time values make a lot of sense in a well-calibrated Predict "what-if" model many will find less value from response times coming into TSCO via a nightly Manager run in comparision to the cost of calculating them. The primary concern is that there are basically four components that contribute to response time: CPU Service Time, CPU Wait Time, I/O Service Time, I/O Wait Time. There is Network Service/Wait but since processes don't carry network activity that isn't assigned directly. In relation to CPU Service Time that is fixed by definition (since a transaction is defined as "100 ms of CPU, on a reference CPU, the IBM 530H" and thus the only variables are CPU Wait Time, and I/O Service/Wait times. The allocation of I/Os at the process level is an art (at best) and there isn't a mapping of I/Os to volumes/disk so your I/O service and wait times are calculated based upon a weighted distribution across devices. So, generally visible changes in workload response times will correlate pretty directly to approaching saturation of some physical resource (CPU or Disk) which would generally be very visible at that hardware level. Some environments may have a use case that isn't being considering here but there is a significant cost in relation to calculating these response time values, significant changes in response time can be triggered by anomalies in the model which can be difficult to identify using only the data available in TSCO (thus requiring a detailed investigation back on the TSCO Gateway Server), and the only model calibration performed by the nightly Manager run is auto-calibrate.
Some users strongly disagree with the above opinion and suggest that since Response Time values distill the system performance down to a single number they can be invaluable during the initial problem determination phase when a performance problem has been reported because they can be used to quickly identify if there is an underlying performance problem that may need to be investigated in more detail.