As we continue to expand and combine our data and applications into enterprisewide applications and layer them in an architecture that adds abstraction and expands usage, we find our database access activity greatly increases. Service layers are being built on top of application interfaces and then connected with various other applications across the enterprise. Designs point programmers at enterprise objects or services as the source of data, rather than data servers and databases. This allows for fast deployment of new software applications and services, and provides great flexibility in the enterprise to adapt to new requirements. It can also result in greatly increased data server access, application server activity, and network traffic. One way to improve the performance of critical applications with this type of architecture is to use data caching.
Data caching is a generic term used to describe any of several techniques for placing critical data, or data commonly accessed, in memory and also possibly closer to the user. There are a few choices for caching; some requiring programming or administration efforts and some requiring no manual involvement at all.
This article will offer some choices for caching, with special focus on the DB2 for z/OS buffers.
The Need for Caching
With large-scale, high-volume applications, our primary concerns are always elapsed time per transaction and CPU consumption on the central server. With modern enterprise implementations taking over as the development standard, the layers of abstraction hide the data access layer, and developers often have no clue about the data access actually happening on the data server. Also, generic development typically results in a proliferation of data access calls.
With modern enterprise design, we find more data server calls than in legacy architectures. For example, one recent high-performance application we worked on executed about three SQL statements per transaction. This was a highly tuned application designed for a specific purpose. In contrast, another high-performance implementation we worked on, which employed a Service-Oriented Architecture (SOA) to implement an enterprise data service layer, executed about 1,000 SQL statements per transaction. This frequency of access is a primary concern for modern implementations. Caching can be extremely helpful in these situations.
Caching can help alleviate several potential performance bottlenecks:
- CPU constraints on the data server
- Network traffic between the user and application server or application server and data server
- DASD access latency.
Figure 1 indicates potential performance bottlenecks in enterprise application architecture. The caching itself can be implemented in several different ways listed here in debatable order of least to most effective:
- DASD caching
- Database caching (in our example DB2 for z/OS)
- Application-level caching
- Client-level caching
- Cache data servers.
Figure 2 highlights our choices for data caching. We’ll examine each type of caching with emphasis on the DB2 buffer pools.