Small number of IOVs – no server stress Explaining differences in COOL stress test results of Andrea and David: Small number of IOVs – no server stress

Summary When the number of IOVs in a COOL IOVs table is 1000, selection via COOL API stresses the server considerably This stress does not happen if table only has 50 IOVs The extra stress caused by querying the last vs. the first IOV in a table is independent to the above assertions Without the index, re-computing statistics causes the server stress to be reduced but just a little With 1000 IOVs, adding index on (IOV_since, IOV_until), causes the server stress to reduce considerably

Testing parameters base line 100 folders 100 channels per folder ~100 Bytes per IV record Statistics is calculated after inserting a few records At test, per folder, bulk read one IOV of all channels Read first IOV Per test, the same data is read by all clients No index on (IOV_since, IOV_until) Number of clients, repeated for: [20,30,40,50] Clients spawned once every 5 seconds Before test start, server memory is not cleaned

Parameters under test Num of IOVs at each IOV table: 50 (Andrea tested with 60 IOVs) vs. 1000 (David tested with 1000 IOVs) Statistics computer recently or not? Existence of index on (IOV_since,IOV_until)

50 IOVs numClients 20 30 40 50 Avg (clientMem%) avg (clientsCP%) (load5) Max (elapsed) Min Test Value Name time 3 73 56 26 33 20 numClients 2005-10-26_09:38 91 1 27 30 2005-10-26_09:40 90 32 40 2005-10-26_09:43 50 2005-10-26_09:47 Test: Small number of IOVs, read first IOV Server: Quite happy: high IO at beginning, mainly CPU later Clients: ~ 90% CPU Avg. elapsed time: steady 26-33 Conclusion: (Library) latch contention is negligible when number of IOVs at table is ~50

50 IOVS, read last IOV numClients 20 30 40 50 Avg (clientMem%) avg (clientsCP%) (load5) Max (elapsed) Min Test Value Name time 3 82 15 13 14 20 numClients 2005-10-26_11:53 79 30 2005-10-26_11:55 1 18 40 2005-10-26_11:58 83 16 50 2005-10-26_12:02 Test: Small number of IOVs, read last IOV (# 49) Server: Very happy: mainly CPU Clients: ~80% CPU Avg. elapsed time: fast ~14 sec Conclusion: When table has only 50 IOVs, reading the last vs. the first IOV does not cause extra server stress

1000 IOVs, no New Index numClients 20 30 40 50 Avg (clientMem%) avg (clientsCP%) (load5) Max (elapsed) Min Test Value Name time 3 6 1 482 362 412 20 numClients 2005-10-26_14:03 11 311 165 222 30 2005-10-26_14:09 278 152 224 40 2005-10-26_14:13 10 326 169 254 50 2005-10-26_14:21 Test: 1000 IOVs per table, no new index, read first IOV Server: High IO and library latch contention Clients: ~10% CPU Avg. elapsed time: slowe ~200-400 sec Conclusion: When table has 1000 IOVs, not having new index on (IOV_since, IOV_until), causes server to do much IO and have library latch contention

1000 IOVs, no New Index,statistics numClients 20 30 40 50 Avg (clientMem%) avg (clientsCP%) (load5) Max (elapsed) Min Test Value Name time 3 16 193 135 166 20 numClients 2005-10-26_14:49 13 1 237 156 194 30 2005-10-26_14:53 7 690 173 472 40 2005-10-26_14:59 8 383 186 288 50 2005-10-26_15:15 Test: 1000 IOVs per table, no new index, read first IOV, after re-compute statistics Server: High IO and library latch contention Clients: ~10% CPU Avg. elapsed time: slowe ~200-400 sec Conclusion: Re-computing statistics did lower library latch contention only for lower number of clients

1000 IOVs, with New Index numClients 20 30 40 50 Avg (clientMem%) avg (clientsCP%) (load5) Max (elapsed) Min Test Value Name time 3 92 31 25 26 20 numClients 2005-10-26_12:59 95 1 27 30 2005-10-26_13:02 91 40 2005-10-26_13:05 90 28 50 2005-10-26_13:09 Test: 1000 IOVs per table, with new index, read first IOV Server: Very happy: mainly CPU Clients: ~90% CPU Avg. elapsed time: fast 26 sec Conclusion: When table has 1000 IOVs, using new index on (IOV_since, IOV_until), server is happy