IT University of Copenhagen

Paulius Juodisius (170786 pjuo)

ReserveWithUs Tuning

Database Tuning II-F2011

Teacher: Philippe Bonnet

Copenhagen, 2011

Part I

ReserveWithUs Tuning
Task 1
Evaluation
In order to determine whether Application server should be installed in separate machine one has to measure application server impact on overall system performance. Application server is based on Java, so main Java process (sun-java6 runtime environment) was observed. Initial application and database server load testing was conducted by making 50 thread (user) parallel requests from a client machine. Persistent monitoring utilizing top program (top -b | grep java) showed that Application server is a lightweight process and in most cases it was using less than 4% of processor time with a maximum jump up to 6% as it can be seen in table 1. The memory consumption was also limited, staying under 3%. Additional monitoring using vmstat (table 2) showed that at the beginning of the test system bottleneck is IO bound due to high number of threads sitting in uninterrupted read (waiting for IO to be done). As soon all data is read and placed in RAM, bottleneck switches and becomes CPU bound with user CPU usage reaching 50% (due to DB2 limitation) and many threads waiting in queue for the processor to be available. So in the chosen testing environment it can be expected that systems performance would improve just slightly by placing Application server on a separate machine. This is due to the fact application server is not performing any IO operations, so only small CPU usage can be saved by distributing servers across multiple machines. This hypothesis was conrmed by tests conducted using JMeter with a test plan shown in gure 2. Total number of parallel requests varied between 10 and 50. All tests were conducted with cold cache. Slight about 3% average improvement in performance was noticed and is displayed in gure 1. Deployed on a secondary machine application server was using up to 10% of processor time.
PID 6722 6722 6722 6722 6722 6722 6722 6722 6722 6722 6722 6722 USER db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 db2inst1 PR 20.00 20.00 20.00 20.00 20.00 20.00 20.00 20.00 20.00 20.00 20.00 20.00 NI 0 0 0 0 0 0 0 0 0 0 0 0 VIRT 1155m 1158m 1162m 1168m 1175m 1180m 1181m 1184m 1184m 1184m 1184m 1184m RES 57m 64m 65m 65m 67m 75m 75m 76m 76m 76m 76m 76m SHR 7580 7588 7612 7612 7652 7652 7652 7652 7652 7652 7652 7668 S S S S S S S S S S S S S %CPU 1 4 5 3 4 6 1 1 0 2 2 3 %MEM 1.5 1.7 1.7 1.7 1.8 2 2 2 2 2 2 2 TIME+ 0:00:02 0:00:02 0:00:02 0:00:02 0:00:02 0:00:03 0:00:03 0:00:03 0:00:03 0:00:03 0:00:03 0:00:03 P 3 3 3 3 3 3 3 3 3 3 3 3 TIME 0:01 0:02 0:02 0:02 0:02 0:02 0:02 0:02 0:02 0:02 0:02 0:02 COMMAND java java java java java java java java java java java java

Table 1: TOP statistics

r 0 0 0 1 41 42 50 50 34 46 34 51 25 49 43 41 20 15 10 0

b 0 0 0 1 9 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0

swpd 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

free 3038960 3041120 3040972 2642216 2516292 2459044 2445160 2398824 2265392 2259404 2211664 2074416 2025284 1935372 1843160 1844772 1845164 1844532 1844704 1845148

bu 5072 5088 5224 5800 6140 6168 6200 6288 6320 6344 6360 6392 6424 6440 6472 6504 6536 7320 7348 7380

cache 259456 256864 256864 643888 751824 807952 821664 867508 999224 1004808 1051268 1189212 1237824 1327660 1419036 1419432 1419312 1419424 1419376 1419388

si 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

so 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

bi 28 0 14 1713 9611 3833 144 194 103 574 128 298 64 61 149 74 107 155 17 95

bo 6 5 0 266 32 17 10 25 15 9 5 15 18 9 10 12 31 34 13 25

in 178 220 209 798 2314 4007 5055 4889 5130 4768 4539 5466 4703 5117 4255 3516 3397 2534 2237 1116

cs 377 310 303 2621 6249 13709 19191 18313 19210 17055 16303 20613 16759 17668 14899 13216 10183 7301 6005 3165

us 8 1 0 2 48 49 49 49 48 49 49 49 49 49 49 49 50 49 50 25

sy 8 0 0 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1

id 83 99 100 89 48 49 49 49 49 49 48 49 49 49 49 49 48 48 49 72

wa 1 0 0 8 2 0 0 0 0 0 0 0 0 0 0 0 0 1 0 2

Table 2: VMSTAT results with 10 second interval

4.5

Throughput (commands/s)

3.5

2.5

1.5

1 App server on main machine App server on secondary machine 0.5 0 5 10 15 20 25 30 35 40 45 50

Number of threads

Figure 1: Total performance depending on application server placement

Figure 2: JMeter test plan

Conclusion
In the event that software and hardware is congured as it was during task 1 evaluation, Application server should be deployed on the same machine as database server. The improvement is not signicant and was only noticed when software was stressed beyond normal capacity which is unrealistic. However in a real world scenario Application server would be responsible for a much wider range of functionality and therefore would likely require isolation from Database Server. For instance, dierent Application server components would provide security, business logic execution, administration, presentation functions and etc.

Task 2
In order to nd appropriate indices all performed DB queries are analyzed. Using results from rst task queries were ordered by execution time. Execution time was also conrmed using Timespent interface. Indices on table keys are already established by default in DB2 database, therefore only additional indices are analyzed. ROOM QUERY Using Timespent interface in addition to reports from task1 one can see that room search is the most expensive query. Therefore rst aim is to nd appropriate indexes to speed up room query. An example of room search query is shown in gure 2.

SELECT H.HOTEL_ID , RDE.ROOM_TYPE , Q.ROOM_TYPE_ID , Q.DATE_START , Q.DATE_STOP , Q.NUMROOMS , Q.TOTAL_PRICE FROM DB2INST1 .HOTEL AS H , DB2INST1 .ROOM_TYPE AS RDE , TABLE ( SELECT RDA.ROOM_TYPE_ID , MIN(RDA.SINGLE_DAY_DATE) AS DATE_START , MAX(RDA.SINGLE_DAY_DATE) AS DATE_STOP , 8 AS NUMROOMS , SUM(RDA. PRICE) AS TOTAL_PRICE FROM DB2INST1 .ROOM_DATE AS RDA WHERE RDA. PRICE < 144 AND RDA.NUMAVAIL >= 8 AND RDA.SINGLE_DAY_DATE >= 2011 05 12 AND RDA.SINGLE_DAY_DATE < 2011 05 21 GROUP BY RDA.ROOM_TYPE_ID HAVING COUNT( ) = ( DAYS( 2011 05 21 ) DAYS( 2011 05 12 ) ) ) AS Q WHERE H. CITY = c i t y 3 8 AND H.COUNTRY = country15 AND H.HOTEL_ID = RDE.HOTEL_ID AND Q.ROOM_TYPE_ID = RDE.ROOM_TYPE_ID; Figure 3: Room search query First lets analyze nested query on table ROOM_TYPE. This query uses three predicates on following columns: SINGLE_DAY_DATE, NUMAVAIL, PRICE. This is a range query, so it should be worth to establish clustering index. A supporting factor is that deals (new records in ROOM_DATE table) are only inserted once a month. CREATE INDEX r o o m d a t e _ c l u s t e r ON d b 2 i n s t 1 . room_date ( single_day_date , numavail , room_type_id , p r i c e ) CLUSTER ALLOW REVERSE SCANS ; During query execution results from nested query are written to temporary table which is inner joined with HOTEL and ROOM_DATE. HOTEL table search uses predicates on COUNTRY and CITY. In addition JOIN operation is performed using equality on HOTEL_ID. Proposed composite index for HOTEL table is show below should provide the fastest access to data. Although this index requires signicant amount of storage space, such can be considered acceptable due to tested hardware capabilities and increased performance. Again, index maintenance is not an issue because hotels are not updated frequently. CREATE INDEX h o t e l _ c o v e r i n g ON d b 2 i n s t 1 . h o t e l ( c i t y , c o u n t r y , d i s t a n c e _ t o _ c e n t e r , r a t i n g , s t a t e , zip_code , s t r e e t , name , h o t e l _ i d ) ALLOW REVERSE SCANS ; To minimize IO reads for ROOM_TYPE table composite index is declared in a sequence the columns are called. CREATE INDEX roomtype_covering ON d b 2 i n s t 1 . room_type ( h o t e l _ i d , room_type_id , room_type ) ALLOW REVERSE SCANS ; All these three indices should signicantly improve query execution time.

HOTEL query In a common scenario (e.g. hotels.com) when searching for a hotel one enters location and date lter. Therefore typical hotel command query would look like: command=s e a r c h _ h o t e l s&c o u n t r y=c o u n t r y 2 3&c i t y=c i t y 4 7& price_max=107& d a t e _ s t a r t =20110531&date_stop =20110614 Such command invokes query shown in gure 4. SELECT H.HOTEL_ID , H.NAME , H.STREET , H. CITY , H.ZIP_CODE , H.STATE , H.COUNTRY , H.RATING , H.DISTANCE_TO_CENTER FROM DB2INST1 .HOTEL AS H , DB2INST1 .ROOM_TYPE AS RDE , DB2INST1 .ROOM_DATE AS RDA WHERE H. CITY = c i t y 4 7 AND H.COUNTRY = country23 AND RDA.SINGLE_DAY_DATE >= 2011 05 31 AND RDA.SINGLE_DAY_DATE < 2011 06 10 AND RDA.NUMAVAIL > 0 AND H.HOTEL_ID = RDE.HOTEL_ID AND RDE.ROOM_TYPE_ID = RDA.ROOM_TYPE_ID; Figure 4: Typical Hotel query This query again joins three tables: HOTEL, ROOM_TYPE and ROOM_DATE. Due to the fact that HOTEL table updates are not frequent, declaring composite index for HOTEL table should not suer from maintenance drawbacks. Most searches include city and country, so this index can also be clustered to put all hotel tuples from same city close to each other in storage device. CREATE INDEX h o t e l _ c o v e r i n g ON d b 2 i n s t 1 . h o t e l ( c i t y , c o u n t r y , d i s t a n c e _ t o _ c e n t e r , zip_code , s t a t e , s t r e e t , name , r a t i n g , h o t e l _ i d ) CLUSTER ALLOW REVERSE SCANS ; It might be worth to declare another index on ROOM_DATE table to cover ROOM_TYPE_ID and SINGLE_DAY_DATE in sequence to increase the eciency of the nested loop join between ROOM_DATE and ROOM_TYPE. CREATE INDEX roomdate_covering ON d b 2 i n s t 1 . room_date ( room_type_id , single_day_date , numavail ) ALLOW REVERSE SCANS ; Other sample queries used issued by application server are listed below. Most of them are simple queries and can utilize default key attribute indices that already exist in database on used tables. One queries (room_date_update) should be satised with indices described before. select select insert update select insert count ( ) from LOGIN where customer_id = 3 1 2 7 8 0 ; v a l u e from LOGIN_COUNTER f o r update ; i n t o LOGIN v a l u e s ( 7 3 4 , 3 1 2 7 8 0 ) ; LOGIN_COUNTER s e t v a l u e = 7 3 5 ; count ( ) from LOGIN where customer_id = 3 1 2 7 8 0 ; i n t o SHOPPING_CART v a l u e s ( 3 1 2 7 8 0 , 2 0 1 1 0 5 2 1 , 2 0 1 1 0 5 2 2 , 1 1 9 9 1 8 , 2 1 , 1 6 3 . 0 ) ;

s e l e c t count ( ) from LOGIN where customer_id = 3 1 2 7 8 0 ; s e l e c t from SHOPPING_CART where customer_id =312780; room_date_update update ROOM_DATE s e t numtaken = numtaken + 2 1 , numavail = numavail 21 where room_type_id = 119918 and single_day_date between 2011 05 21 and 2011 05 22 ; i n s e r t i n t o BOOKED v a l u e s ( 3 1 2 7 8 0 , 2 0 1 1 0 5 2 1 , 2 0 1 1 0 5 2 2 , 1 1 9 9 1 8 , 2 1 , 1 6 3 . 0 , 2 ) ; d e l e t e from LOGIN where customer_id = 3 1 2 7 8 0 ;

Evaluation
After indices were dened, reorg commands were issues to defragment table and index storage structures. At this point indices impact can be measured. Query execution time before and after index declaration is compared. In addition it should be checked whether new indices are used at all for queries. Index impact on query execution is displayed in gure 4. In addition indices that were suggested by db2advis tool are tested. Suggested indices are displayed in below: CREATE INDEX DB2INST1 . IDX1105161019230 ON DB2INST1 .ROOM_TYPE (HOTEL_ID ASC, ROOM_TYPE_ID ASC) ALLOW REVERSE SCANS ; CREATE INDEX DB2INST1 . IDX1105161019260 ON DB2INST1 .HOTEL (CITY ASC, COUNTRY ASC, DISTANCE_TO_CENTER ASC, RATING ASC, STATE ASC, ZIP_CODE ASC, STREET ASC, NAME ASC, HOTEL_ID ASC) ALLOW REVERSE SCANS ; CREATE UNIQUE INDEX DB2INST1 . IDX1105161021050 ON DB2INST1 .ROOM_DATE (ROOM_TYPE_ID ASC, SINGLE_DAY_DATE ASC) INCLUDE (NUMAVAIL) ALLOW REVERSE SCANS ; CREATE INDEX DB2INST1 . IDX1105161021300 ON DB2INST1 .ROOM_DATE (SINGLE_DAY_DATE ASC, NUMAVAIL ASC) ALLOW REVERSE SCANS ; CREATE INDEX DB2INST1 . IDX1105161021540 ON DB2INST1 .HOTEL (CITY ASC, COUNTRY ASC, HOTEL_ID ASC) ALLOW REVERSE SCANS ; CREATE INDEX DB2INST1 . IDX1105161022100 ON DB2INST1 .ROOM_TYPE (HOTEL_ID ASC, ROOM_TYPE ASC, ROOM_TYPE_ID ASC) ALLOW REVERSE SCANS ;
3500 No Index 3000 With Indices Execution time (ms) 2500 With db2advis indices 2000 1500 1000 500 0 Insert into hotel Room query Hotel query With merged indices

Query

Figure 5: Query performance 7

Query benchmark show that room query performance improved 20% and hotel query 55%. On a negative side inserts into hotel table slowed down approximately 5 times. However such operation occurs seldom and should not be a concern. It can also be seen that from room query point of view indices outperform db2advis suggested indices. However Hotel query is indeed performed faster using db2advis indices. So perfect solution for this situation would a be a merge between chosen indices and db2advis ones. Merged index set is shown below and benchmark results are displayed in gure 4 last column. CREATE INDEX h o t e l _ l i g h t _ c o v e r i n g ON d b 2 i n s t 1 . h o t e l ( c i t y , country , h o t e l _ i d ) ALLOW REVERSE SCANS ; CREATE INDEX roomtype_covering ON d b 2 i n s t 1 . room_type ( h o t e l _ i d , room_type_id , room_type ) ALLOW REVERSE SCANS ; CREATE INDEX r o o m d a t e _ c l u s t e r ON d b 2 i n s t 1 . room_date ( single_day_date , numavail , room_type_id , p r i c e ) CLUSTER ALLOW REVERSE SCANS ; CREATE INDEX h o t e l _ c o v e r i n g ON d b 2 i n s t 1 . h o t e l ( c i t y , c o u n t r y , d i s t a n c e _ t o _ c e n t e r , zip_code , s t a t e , s t r e e t , name , r a t i n g , h o t e l _ i d ) CLUSTER ALLOW REVERSE SCANS ; CREATE UNIQUE INDEX roomdate_newUniqueIndex ON DB2INST1 .ROOM_DATE ( room_type_id , single_day_date ) INCLUDE ( numavail ) ALLOW REVERSE SCANS ; In the last place index participation was tested using db2 explain tool (db2expln). Results conrmed that all indices are involved in query execution plans.

Task 3
There are several ways to back up and load table data in DB2. One way is to use Export and Import command accordingly. Export command can save data in various format and in this assignment IXF and DEL are considered. File in IXF format (proprietary binary format) includes data and table schema information as well as indices. File in DEL saves data in simple comma separated value style. It is expected that IXF format le would take more space and would require more time to generate. However additional redundant information (schema and indices) are saved and is not used later then importing back to customer table. In this assignment these export commands are considered: Export IXF EXPORT TO c u s t o m e r s . i x f OF IXF SELECT FROM customer ; Export DEL EXPORT TO c u s t o m e r s . d e l OF DEL SELECT FROM customer ; Execution time was primary concern and experiments were conducted by enforcing cold cache. Customer table consisted 100000 records with average row size of 262B. Results are shown in table 3. Exporting in DEL format is faster so it is more suitable for this assignment. Export IXF 136.6585 407.9Mb Export DEL 95.61367 222.3Mb Table 3: Export benchmark results There couple ways in how data can be deleted: LOAD FROM empty . d e l o f DEL REPLACE INTO d b 2 i n s t 1 . customer ALLOW NO ACCESS ; DELETE FROM d b 2 i n s t 1 . customer ; First command performed very quickly in 5s. DELETE command failed with error The transaction log for the database is full.. So to delete data LOAD command with REPLACE option is very ecient and is preferred for use in ReserveWithUs application. Exported data can be imported using IMPORT or LOAD command. IMPORT command is a reverse to Export command and in low level uses SQL insert statements. It can also recreate table according to original 8

Average time (s) Average le size

schema if le is in IXF format. Load command is faster because it does not check if data is consistent to existing constraints. To achieve that set Integrity command has to be used after loading data. However it does not call triggers if they exist. Load is an ecient way of loading high volume of data into tables because it writes pages directly to database storage instead of using SQL INSERT. This is the reason why LOAD is expected to be a more suitable solution in this assignment. LOAD FROM /home/ d b 2 i n s t 1 / dbtun2 / c u s t o m e r s 2 . d e l OF DEL INSERT INTO d b 2 i n s t 1 . customer ALLOW NO ACCESS SET INTEGRITY PENDING CASCADE IMMEDIATE; IMPORT FROM /home/ d b 2 i n s t 1 / dbtun2 / c u s t o m e r s 2 . d e l OF DEL COMMITCOUNT AUTOMATIC INSERT INTO d b 2 i n s t 1 . customer ; Execution time was measured and results are displayed in table 4. It is clear that Load option is signicantly faster and suits ReserveWithUs needs better. Import 725.97 Load 37

Average execution time (s)

Table 4: Import procedure execution time So the import/export procedure would look like this: EXPORT TO c u s t o m e r s . d e l OF DEL SELECT FROM customer ; LOAD FROM empty . d e l o f DEL REPLACE INTO d b 2 i n s t 1 . customer ALLOW NO ACCESS ; LOAD FROM /home/ d b 2 i n s t 1 / dbtun2 / c u s t o m e r s 2 . d e l OF DEL INSERT INTO d b 2 i n s t 1 . customer ALLOW NO ACCESS SET INTEGRITY PENDING CASCADE IMMEDIATE;

Task 4
Checkout function is a synchronized Java method which performs four SQL statements in one transaction. In addition it includes a 4 second automatic wait for customer to conrm the order. Multiple contentions may happen. Because checkout is a synchronized method, it has to wait for intrinsic lock on Shopping-Cart object before it is executed. However this behavior can not be changed because it may return inconsistent results.

Transaction chopping
Checkout function includes four statements of which three are updating tuples. Therefore while executing these statements db2 query processor has to acquire exclusive locks on 3 tables and keep them for the whole time. Table 5 displays all statements and conicting transactions. It may cause other reading transactions to wait for extensive period. Statement description get_shopping_cart update room_date insert into booked empty shopping cart Operation R/W (table name) R (shopping_cart) W (room_date) W (booked) W (shopping_cart) Conicting transaction nd_hotel, nd_room add_to_shopping_cart

Table 5: SQL Statements Using algorithm from Database Tuning book Appendix B, checkout transaction can be chopped to multiple transactions. Proposed transactions are shown in table 6.

Transaction identier T1 T2 T3

Statements get_shopping_cart, empty shopping cart update room_date insert into booked

Operation R (Shopping_cart), W (shopping_cart W (room_date) W (booked)

Table 6: Proposed chopped transactions

Lack of resources
New test plan (gure 6) was assembled with higher number of addToCart, browse hotel and browse rooms commands so that pressure on checkout transaction is increased. Investigation of vmstat output during a test execution showed that bottleneck switches intermittently between CPU-bound and IO-bound. Timespent interface output (pool_index_p_reads) was constantly returning high numbers which means that indices are not cached in buer all the time. Default buer pool size was increased to 400000 pages (4K page size = 1.6GB of RAM needed) which is more than 319596 pages used by DB. So in reality the whole database could be cached in RAM. Performance gain after increasing buer pool is very signicant as it can be seen in gure 7. Throughput have increased about 600%.

Figure 6: Test plan for checkout transaction testing

10

24 Default buffer pool size 22 Increased buffer pool size 20 18 Throughput (request/s) 16 14 12 10 8 6 4 2 Bufferpool management

Figure 7: Buer pool increase impact

Automatic 4 second wait

Every checkout command takes at least 4 seconds to conduct due to the 4 second user interaction wait. Wrapping user interaction session inside of a transaction is inecient and should avoided. User may take extensive amount of time to make a decision and it could cause concurrency issues because locks are held for a prolonged time. A suggestion in ReserveToUs instance would be to to introduce checkout_conrmation command which would perform tasks shown in table 5 without any delay. To satisfy such command, BOOKED relation order_status attribute could be used to transition between pending orders and conrmed orders. In the mean time checkout command functionality would decrease.

Task 5
Sample Hotel query with distance parameter is show below: SELECT H.HOTEL_ID , H.NAME , H.STREET , H. CITY , H.ZIP_CODE , H.STATE , H.COUNTRY , H.RATING , H.DISTANCE_TO_CENTER FROM DB2INST1 .HOTEL AS H , DB2INST1 .ROOM_TYPE AS RDE , DB2INST1 .ROOM_DATE AS RDA WHERE H. CITY = c i t y 4 7 AND H.COUNTRY = country23 AND RDA.SINGLE_DAY_DATE >= 2011 05 31 AND RDA.SINGLE_DAY_DATE < 2011 06 10 AND RDA.NUMAVAIL > 0 AND H.DISTANCE_TO_CENTER < 5 AND H.HOTEL_ID = RDE.HOTEL_ID AND RDE.ROOM_TYPE_ID = RDA.ROOM_TYPE_ID; This query can take advantage of clustered index on hotel table that already is established. Thereby, no extra indices are required in order to speed up this query.

11

CREATE INDEX h o t e l _ c o v e r i n g ON d b 2 i n s t 1 . h o t e l ( c i t y , c o u n t r y , d i s t a n c e _ t o _ c e n t e r , zip_code , s t a t e , s t r e e t , name , r a t i n g , h o t e l _ i d ) CLUSTER ALLOW REVERSE SCANS ;

Part II

Logbook
1 Hardware
Lenovo x201 (Primary) Intel i5-480M 2.66Ghz 2/4 4GB 7200RPM Ubuntu Server 11.04 64bit with LXDE HP nx6325 (Secondary) AMD Turion X2 TL-60 2Ghz 2/2 3.2GB 5400 RPM Ubuntu 11.04 64bit Two machines were used during this project. Hardware conguration is shown in table 7. Description Processor Cores/Threads (Logical CPU Cores) RAM HDD speed OS

Table 7: Hardware conguration To emulate real world server environment, IBM DB2 Express C database server was installed on a dedicated OS (Ubuntu 11.04 Server Edition with LXDE desktop environment) in the primary machine. DB2 was installed without any issues using DB2 installation wizard. Machines were connected using single Ethernet cable without using any routing devices.

Log
Primary dilemma was to nd a proper benchmark setup which would apply realistic load and provide consistent results. It was especially important for the rst question in order to nd application server impact on whole system. Measures had to be taken from a client side because it is mainly the client or customer who would feel the dierence of shorter waiting times. Instead of writing a benchmark script I have decided to utilize a very suitable tool for such occasion called JMeter. This Java application is designed to apply customized load in a very organized way and can provide functional and nonfunctional testing measurements. To simulate a real world scenario I have made a test plan (shown in gure 2 and gure 6) where one user (one thread) performed set number of tasks in a random order so that load is uniformly distributed. Multiple loops were conducted to ensure that average results are objective. To ensure that CPU is not used during testing while generating random command parameters, CSV le was generated by a script before every experiment. Each CSV line contained commands with unique parameters that represented a single user activities during the experiment. Testing client was sending high number of parallel TCP requests, so application thread pool was increased to 200. After loading initial data to DB tables, login command was not working. It was resolved by setting correct counter value. Solution was posted in blogs.

i n s e r t into login_counter values ( 1 ) ; For each experiment to be comparable cold cache had to be enforced using:

12

db2stop f o r c e sudo sync echo 3 | sudo t e e / p r o c / s y s /vm/ drop_caches db2start Supplied application did not performed administration functions, therefore I had to write extra SQL commands for inserting records to hotel and room_date tables. This was done to measure index impact on maintenance operations. Increased execution time was not considered harmful because updates occur seldom only once or twice a month. However in real world scenario new deals are inserted all the time and therefore index maintenance would play bigger role. There was dilemma on how to nd true query execution time. DB2 Timespent interface was chosen instead of running python script or JMeter test plan in an eort to solely concentrate only on DB2 process without depending on other frameworks. Indices were not fully operational until reorg and runstats commands were called in: REORG TABLE d b 2 i n s t 1 . h o t e l ALLOW NO ACCESS ; REORG INDEXES ALL FOR TABLE d b 2 i n s t 1 . h o t e l ALLOW NO ACCESS ; RUNSTATS ON TABLE d b 2 i n s t 1 . h o t e l AND SAMPLED DETAILED INDEXES ALL ; When performing export using IXF format I noticed that ntfs-3g process is taking about 75% processor time and whole export procedure was taking over 16 minutes on average. However this aw did not aect export in DEL format. Execution time was the same when le was saved to EXT4 and NTFS. PID USER 730 r o o t PR 20 NI VIRT RES 0 17316 1620 SHR S % CPU % MEM 756 S 73 0 . 0 TIME+ P 34:55.35 0 TIME COMMAND 3 4 : 5 5 mount . n t f s 3g

File was saved in a partition which uses NTFS, so I switched working directory to a path in EXT4 le system partition. After the switch export procedure execution time dropped to just over 2 minutes. Export execution time was measured using Unix Time tool. time db2 t f e x p o r t . s q l Timespent query was written to export all statements that occurred during a test in order to analyze reading/writing time, lock waiting time, number of physical page read information and etc. export to waiters . csv of del s e l e c t s u b s t r ( stmt_text , 1 , 6 0 0 ) stmt_text , stmt_exec_time , total_act_wait_time , lock_wait_time , log_buffer_wait_time , log_disk_wait_time , fcm_recv_wait_time , fcm_send_wait_time , pool_read_time , pool_data_p_reads , pool_index_p_reads , pool_write_time , direct_read_time , direct_write_time from t a b l e ( mon_get_pkg_cache_stmt ( d , n u l l , n u l l , 1)) a s x o r d e r by stmt_exec_time d e s c ;

13