Performance Of Transaction Processing Systems Research Articles

A pipeline-based approach for long transaction processing in web service environments

In web service environments, long transactions need to lock resources – often database services – for a long time during their long execution duration. This would bring down the performance of transaction processing systems. The transaction compensation is a feasible solution through allowing sub-transactions to independently commit, however, it is not able to speed up the transaction processing. This paper proposes a novel pipeline-based transaction processing (PLbTP) model for Serial Long Transactions (SLTs), which parallelises the transaction processing to reduce the transaction execution duration. Furthermore, we design a time-stamp-based deadlock prevention mechanism for the control of multiple concurrent transactions. The simulation results demonstrate that our approach can significantly improve performance of SLTs without the aid of compensating transactions.

A more realistic locking model and its analysis

The performance of transaction processing systems as affected by standard locking, i.e., the strict two-phase locking concurrency control method with the general waiting policy, has been reported in numerous studies based on analytic solutions and simulation. However, most studies assume a homogeneous database access model, i.e., all transactions follow the same access pattern of uniform or nonuniform database accesses. This paper is a major departure from previous works in that it considers a heterogeneous database access model, i.e., there are multiple transaction classes and accesses of each transaction class to the different regions of the database for different transaction steps is determined according to transaction's input parameters and the database state. The performance of the system is analyzed using an approximate low-cost iterative solution method, whose accuracy is ascertained by validation against simulation results. Numerical examples are provided to gain a better understanding of the implications of the model on the performance of transaction processing systems, with special attention being paid to the issue of detecting the onset of thrashing. The insights gained from this study should be useful in developing transaction scheduling methods to prevent thrashing.

Performance analysis of concurrency control using locking with deferred blocking

The concurrency control (CC) method employed can be critical to the performance of transaction processing systems. Conventional locking suffers from the blocking phenomenon, where waiting transactions continue to hold locks and block other transactions from progressing. In a high data contention environment, as an increasing number of transactions wait, a larger number of lock requests get blocked and fewer lock requests can get through. The proposed scheme reduces the blocking probability by deferring the blocking behavior of transactions to the later stages of their execution. By properly balancing the blocking and abort effects, the proposed scheme can lead to better performance than either the conventional locking or the optimistic concurrency control (OCC) schemes at all data and resource contention levels. We consider both static and dynamic approaches to determine when to switch from the nonblocking phase to the blocking phase. An analytical model is developed to estimate the performance of this scheme and determine the optimal operating or switching point. The accuracy of the analytic model is validated through a detailed simulation. >

Performance issues in database systems

The performance of transaction processing systems is affected by contention for hardware as well as software resources (data objects). Software contention becomes prominent in database systems because concurrency control mechanism, which is used to insure integrity of the database, restrict concurrent and conflicting access to data objects of a database. Locking is the most popular scheme to achieve concurrency control in database systems. Performance of a database system is greatly determined by its underlying concurrency control algorithm because it determines the performance degradation in presence of software contentions. In this paper, we will examine the issues in the performance analysis of concurrency control algorithms and their affect on the overall database system performance. With many alternatives now available to design a database system, there is a tremendous need to assess the suitability of a design to a particular environment and need. In this paper, we will discuss difficulties in modeling concurrency control algorithms and describe how these difficulties have been overcome.

Panel: Database system performance management

In the past few years we have seen in the literature a number of proposals for benchmarks to be used in measuring the performance of database management and transaction processing systems. The TP1 benchmark [Anon et al 1985] and the Wisconsin benchmark [Bitton et al 1983], [Boral and DeWitt 1984], and [Bitton and Turbyfill 1985] have been used to benchmark several systems. Other benchmarks have also been proposed. The TP1 benchmark actually consists of three different benchmarks Debit-Credit, Scan, and Sort. It is oriented towards transaction processing systems. Each of the benchmarks consists of a single transaction type and operates on a large database — around 10 GBytes. The database consists of artificial data but is modeled around data maintained by a large bank. The Debit-Credit benchmark consists of a transaction that reads and updates a small number (about 4) of random records. It imposes stringent response time and throughput requirements on the system. The Scan benchmark consists of a COBOL program that exercises the system by executing 1,000 scan transactions each of which accesses and updates 1,000 records in a sequentially organized file. Finally, the Sort benchmark sorts 1M records of 100 bytes each. Each of the benchmarks stresses different aspects of the system. Each requires different amount of CPU, communication, and I/O cycles. In addition to the diversity of system resource requirements the benchmark methodology described in [Anon et al 1985] also requires that the cost of the system be calculated. Thus, the final measure one obtains from running the TP1 benchmark is $K/TPS. Whereas TP1 is oriented towards transaction processing the Wisconsin benchmark was conceived for the purpose of measuring the performance of relational database systems. It consists of two parts a single user benchmark in which a suite of approximately 30 different queries are used to obtain response time measures in standalone mode (described in [Bitton et al 1983], and a multi-user benchmark in which several queries of varying complexity are used to determine the response time and throughput behavior under a variety of conditions (one version of the multi-user benchmark is described in [Boral and DeWitt 1984] and a second version in [Bitton and Turbyfill 1985]). The test database consists of a number of relations of varying sizes. The relations are generated according to statistical distributions and do not model any real world data. Users of the benchmark can modify the database generator routines to adapt the database characteristics so that they are more representative of their application. It appears as though both the TP1 and the Wisconsin benchmark have the potential of becoming de facto standard benchmarks, in their respective areas, to be used in a variety of ways. For example, a vendor could use the benchmarks to stress test a system under development. Another use for a vendor is in establishing a particular rating for a system (equivalent MIPS Whetstones, etc. for mainframes). Finally, a user can use a benchmark to compare several systems before purchasing one. The purpose of this panel is to discuss the use of benchmarking for measuring the performance of transaction processing systems and database management systems in general and the use of the TP1 and Wisconsin benchmarks in particular. The panelists have been chosen so that we have a representation of experts in the particular benchmarks (Gawlick) and DeWitt), a benchmark “consumer” (Hawthorn), and a “performance expert” — someone who understands benchmarking as a science/art (Brice). The panelists will address the following issues (as well as others raised by the audience) What are the strengths and weaknesses of the TP1 and Wisconsin benchmarks? Is benchmarking a good technique for measuring the performance of data management and transaction processing systems? What can these benchmarks tell us about a system and what can they not tell us about it?

Performance Evaluation of Centralized Databases with Static Locking

The performance of transaction processing systems is determined by the contention for hardware as well as software resources (database locks), due to the concurrency control mechanism of the database being accessed by transactions. We consider a transaction processing system with a set of dominant transcation classes. Each class needs to acquire a certain subset of the locks in the database before it can be processed, i.e., predeclared lock requests with static locking. Straightforward application of the decomposition method requires the numerical solution of a two-dimensional Markov chain. Equivalently, a hierarchical simulation method, where the computer system is represented by a composite queue with exponential service rates, can be used to analyze the system. We propose an inexpensive analytic solution method, also based on hierarchical decomposition, such that the throughput of the computer system ic characterized by the number of active transactions (regardless of class). Numerical results are provided to show that the new method is adequately accurate compared to the other two rather costly methods. It can be used to determine the effect of granularity of locking on system performance. The solution method is also applicable to multiresource queueing systems with multiple contention points.