Characterising Workloads

To produce I/O cost predictions using MaStA for AISP, DataSafe and the LSD, the applications are analysed to determine the values assigned to the MaStA workload variables described in Table 4.3.

7.4.1 The Building Society’s Workload

The predicted workload of the building society is analysed using 40000 transactions. This number of transactions is assumed to be sufficiently large to accurately represent the characteristics of the application when it is executing continuously on the three recovery mechanisms available. The analysis is broken down by calculating the contribution to each workload variable made by three sets of objects: indexing information, customer bitmap objects and the remaining objects composing customer records. Analysis is performed in this manner to reflect the layout of these objects in the database (Figure 7,2).

Since the B+tree index is accessed frequently, it is assumed that each page (8 Kbytes) containing nodes of the index is faulted only once and remains in the database cache (8 MB). Hence it is assumed that the minimum number page faults, i.e. 384 faults, are incurred when accessing the 3 MB (384 pages) of indexing information, and that good locality (90%) is observed of these faults. The workload values attributed to reading indexing information are estimated to be:

read = 48000 (16000 Nodes * 3 objects) readRecent = 47616 {read - page faults)

readFauULoc = 346 (90% of page faults)

A total of 42000 customers are accessed (95% of 40000 transactions * 1 customer + 5% of 40000 transactions * 2 customers), requiring 42000 read to access the corresponding bitmap objects. Since accesses to the bitmaps are sparse, readRecent is assigned 0, i.e. each bitmap access causes a page fault.

The c u s to m e r structure instance, name, address and image descriptor objects of a customer contribute 168000 to read (42000 customers * 4 objects). The objects of a particular customer are assumed to reside on the same page. Therefore readRecent is

assigned 126000 * read) since three out of four read for each customer, access the same page. Since a number of customer records reside on each database page some degree of temporal locality (10%) is assumed in customer accesses. Therefore an additional 4200 (10% of 42000 customers) is assigned to readRecent.

Due to the unclustered nature of this workload, it is assumed that the degree of spatial locality of customers accessed is poor: only 10% of page faults are clustered. Hence customer bitmap accesses contribute 4000 to readFauULoc (10% of read - readRecent for bitmaps). The value of readFauULoc for accessing other customer objects is 3360 (10% of read - readRecent for the other customer objects).

The building society predicts that 5% of transactions update the balances of the customer records they access. It is assumed that the objects containing the balances of the two customers updated by each transaction are held on different pages and hence two pages are updated by each transaction. An additional three pages are updated for each transaction commit to record NapierSS overheads.

update = 10000 (2000 update transactions * 5 pages) updateTrans = 0

Workload Variables Values

read 258000 pages readRecent 177816 pages readFauULoc 8018 pages update 10000 pages updateTrans 0 pages updateLoc 5% commit 2000 propWrite 4488 pages propWriteFinal 512 pages page 8192 bytes mapEntry 8 bytes root 1 db 270 MB

Table 7.1: Variable Values for the Building Society’s Workload

The temporal locality of the pages updated by transactions is assumed to be high since these pages contain customer balances that are frequently updated, and hence infrequently chosen for replacement in the cache. Therefore it is assumed that a high proportion of pages (50%) updated in the cache by transactions are updated,again by

other transactions before being propagated to the database in the DataSafe mechanism.

propWriteFinal = 512

propWrite — 4488 ((50% of update) - propWriteFinal)

The value of propWriteFinal is estimated to be 50% of the size of the database cache (1024 pages) used by the recovery mechanisms. Table 7.1 provides a summary of the workload variable values used to characterise the predicted database workload of the building society.

7.4.2 The Bank’s Workload

The database workload predicted by the bank is analysed using 20000 transactions, as opposed to the 40000 transactions of the building society to make the workloads generated from the two applications comparable. The workload variable values for reading indexing information in the bank’s application are assumed to be similar to those of the building society’s.

A total of 39000 customers (5% of 20000 transactions * 1 customer + 95% of 20000 transactions * 2 customers) are accessed with similar degrees of temporal and spatial locality to the building society’s predicted workload. The workload values attributed to reading indexing and customer information are:

read - 48000 (for index objects) + 39000 (for customer bitmaps)

+ 156000 (39000 customers * 4 objects) readRecent = 47616 (for index objects)

+ 0 (for customer bitmaps)

+ 120900 (39000 customers * 4 objects * + 10% of 39000 customers)

readFauULoc = 346 (for index objects)

+ 7253 (10% of read-readRecent for all customer objects)

In the bank’s predicted workload 95% of transactions update the balances of the customer records they access and similarly to the building society’s workload each transaction updates 5 pages.

update = 95000 (19000 update transactions * 5 pages) updateTrans — 0

Workload Variables Values read 243000 pages readRecent 168516 pages readFauULoc 7448 pages update 95000 pages updateTrans 0 pages updateLoc 5% commit 19000 propWrite 46732 pages propWriteFinal 768 pages page 8192 bytes mapEntry 8 bytes root 1 270 MB

Table 7.2: Workload Variable Values for the Bank’s Workload

Similarly to the building society’s workload 50% of pages updated in the cache by transactions are assumed to be updated by other transactions before being propagated to the database in the DataSafe mechanism.

propWriteFinal propWrite =

768

46732 ((50% of update) - propWriteFinal)

The value of propWriteFinal is estimated to be 75% of the size of the database cache (1024 pages) - a higher percentage than the building society since a higher proportion of the pages accessed are updated. The values assigned to the workload variables for the bank are summarised in Table 7.2,