© 2007, IBM, Washington Systems Center Version 10/23/2007
http://www.ibm.com/support/techdocs
Heuristic Conversion of CF Operations Page
3
The heuristic drives requests to the CF in the appropriate synchronous or asynchronous
execution mode, based on the actual observed service times for similar requests. At the
same time, CF lock structure requests were also enabled for asynchronous execution
based on the heuristic, similar to list and cache structure requests.
The heuristic dynamically monitors actual observed synchronous CF request service
times, at a fine granularity, for each type of CF command, on a per-CF basis (and on a
per-pair-of-CFs basis for those CFs participating in System-Managed CF Structure
Duplexing). This monitoring also takes into account the amount of data transfer requested
on the operation, and several other request-specific operands which can significantly
influence the service time for the request. These observations are then recorded in a
table, organized by request type and the other factors described above, in which z/OS
maintains a moving weighted average synchronous service time for each specific
category of request. This moving, weighted average is biased towards recent history, so
z/OS can react responsively to factors suddenly affecting a CF’s performance, such as a
sudden workload spike.
The heuristic then compares these actual observed synchronous service times against
dynamically calculated thresholds, in order to determine which kinds of operations would
be more efficient if they were to be executed asynchronously. z/OS calculates several
different thresholds for conversion – reflecting the fact the relative costs of asynchronous
processing for list, lock, and cache requests are not the same, nor are the relative costs of
asynchronous processing for simplex and duplexed requests the same. All of the
calculated thresholds are then normalized based on the effective processor speed of the
sending processor (which in turn incorporates information about both the intrinsic
processor speed of the machine, and multiprocessing effects based on the number of CPs
online for the z/OS image at the time), to accurately reflect the “opportunity cost” of
synchronous execution for the processor on which z/OS is executing. The heuristic and
the calculation of these conversion thresholds are not externally adjustable in any way.
As CF requests are submitted for processing, the characteristics of each request are
examined to determine the recently-observed performance of similar requests. If z/OS
determines similar requests have been experiencing good performance (i.e. the moving
weighted average service time of those requests is below the calculated threshold for
conversion), then z/OS will direct the current request to be executed synchronously. If
z/OS determines similar requests have been experiencing poor performance (i.e. the
moving weighted average service time of those requests is above the calculated threshold
for conversion), then z/OS will convert the current request to asynchronous execution if it
is possible to do so.
Note z/OS will occasionally “sample” synchronous performance for CF requests even
when the heuristic has determined it would be more efficient to perform the request
asynchronously, by performing every N
th
request of a given type synchronously. This
mechanism ensures if some factor should change which results in the CF’s performance
improving, the improvement will be observed and acted on. Thus, the heuristic does not