The model is configured i n a two-level h ierarchy, a high level and a detailed level. The use of a hierarchy allows a complex and deta i led model that considers many components and involves many parameters to be constructed easily. Because of the hierarchical approach, the model also provides flex i b i l ity for modifications and extensions, and validation of separate submodels.
The high-level model assumes the decomposition of transaction response t imes, as described in the Response Time Components section, and models the behavior of the transact ion p rocessi ng system by an open queu i ng system, as shown in Figure 10. The queu i ng system consists of servers and delay centers, which are connected in a queu i ng net work w i t h the fol lowing assumptions:
• The front-end processing does not i nvolve any d isk 1/0 operation, and the load on the front end systems is equally balanced.
I
COMMUNICATIONI
FRONT-ENDI
COMMUNICATIONI
BACK-END END-TO-ENDRESPONSE TIME
Figure 9 Response Time Components
Transaction Processing, Databases, and Fault-tolerant Systems
COMMUN ICATION
COMMUNICATION
{8
:
DELAYSFRONT-END
PROCESSORS BACK-END PROCESSORS 1/0 DEVELOPMENT
1/0 DEVELOPMENT
Figure 10 High-level Queuing Model for a Transaction Processing System
• The back-end is a shared-memory multiprocessor
system with symmetrical loads on al l processors (or it can be simply a u niprocessor).
• No intratransact ion parallelism exists within i nd ividual transaction execution.
• No m u tual dependency exists between trans action response t ime components.
• Transaction arrivals tO the processors have a
Poisson distribu tion.
These assumptions correspond to Digital's TPC Bench mark A testing methodology and implementation.
The front-end CPU is modeled as an M/M/1 queu ing center, and the back-end CPU is modeled as an M/M/m queui ng center. The transactions' CPU times on the front-end and back-end systems are assumed to be exponentially d istributed (coefficient of vari ation equal tO 1) due to the s ingle type of trans action i n the benchmark. (Note: An approx imatio n o f M/G/m can b e used to consider a coefficient of variation other than 1 for the back-end transact ion
CPU service time, especially in the m u lt iprocessor case when the bus is highly ut ilized .) Database 1/0, logging 1/0, and other delays are modeled as delay centers, with appropriate delay distributions. For the model of the TPC Benchmark A workJoad, the database I/0, journal i ng 1/0, and other com muni cation and synchro n ization delays are combined into one delay center, cal led the LOD delay center, which is represented by a 2-Erlang d istribu tion. The major input parameters for this h igh-level model are the
• Number of front-end systems and the front-end CPU service t ime per transaction
54
• Nu mber of CPUs in the back-end system and the
back-end CPU service time per transact ion
• Sum of the back-end database 1/0 response time, journa l i ng 1/0 response time, and other delay t imes (i .e. , the mean for the LOD delay center's 2-Erlang d istribution)
• Response t ime constra int (in the form of x per centi le less thany seconds)
The m a i n result from the high-level model is the MQTh. This high-level model presents a global pic ture of the performance behavior and manifests the relationship between the most important parameters of t he transaction process i ng system and MQTh.
Some of the input parameters i n the h igh-level model are dynam ic. The CPU service t ime of a trans action may vary with the throughput or number of processors, and the database 1/0 or other delays may also depend on the throughput. A good exam ple of a dynamic model is a tightly coupled multi processor system, with one bus interconnecting the processors and with a shared common memory (e.g. , a VAX 6000 Model 440 system). Such a system would run a s i ngle copy of the symmetrical multi processing operati ng system (e.g . , the
VMS
system). The average CPU service time of t ransactions is affected by both hardware and software factors, such as• Hardware contention that results from conflict ing accesses to the shared bus and main memory and that causes processor speed degradation and longer CPU service t ime.
• Processor synchronization overhead that results
from the serializat ion of accesses to shared data
structures. Many operating systems use spin locks as the mechanism for p rocessor- level synchronization, and t he processor spins (i .e., busy-wa i ts) in the case of a confl ict. I n the model, the busy-wa it overhead is considered to be part of t he t ransaction code path, and such contention elongates the transaction CPU service time.
Four deta i led-level submodels are u sed to account for the dynamic behavior of these param eters: CPU-cache-bus-memory, busy-wa it, I/0 group, and LOD.
The CPU-cache-bus-memory submodel cons ists of many low-level parameters associated with the workload, processor, cache, bus, and memory com ponents of multiprocessor systems. It models these components by using a m ixed queui ng network model that consists of both open and closed cha ins, as shown in Figure 1 1 . The most important outpu t from this submodel is t he average number of CPU clock cycles per instruction.
The busy-wa it submodel models t he spi n-lock contention that is associated with t he two major VMS spin-locks, called SCHED and IOLOCK8. This sub model d ivides the state of a processor into several nonover lapping states and uses probabi lity analy sis to derive busy-wait t ime. The I/O grouping sub model models the group com m i t and group write mechanisms of the VAX Rdb/VMS relational database management system. This submodel affects the path length of transaction because of the amorti zation of disk I/O processi ng among grouped trans actions. The LOD submodel considers t he d isk I/0 t imes and the lock contention of cert a i n crit ical resources in the VAX Rdb/VMS system.