1. 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

2. 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

3. 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

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

5. 50 IOVs
numClients
Avg
(clientMem%)
avg
(clientsCP%)
(load5)
Max
(elapsed)
Min
Test
Value
Name
time 3 73 56 26 33 20
numClients
_09:38 91 1 27 30
_09:40 90 32 40
_09:43 50
_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

6. 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
_11:53 79 30
_11:55 1 18 40
_11:58 83 16 50
_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

7. 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
_14:03 11
311
165
222 30
_14:09
278
152
224 40
_14:13 10
326
169
254 50
_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 ~ 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

8. 1000 IOVs, no New Index,statistics
numClients
Avg
(clientMem%)
avg
(clientsCP%)
(load5)
Max
(elapsed)
Min
Test
Value
Name
time 3 16
193
135
166 20
numClients
_14:49 13 1
237
156
194 30
_14:53 7
690
173
472 40
_14:59 8
383
186
288 50
_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 ~ sec
Conclusion: Re-computing statistics did lower library latch contention
only for lower number of clients

9. 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
_12:59 95 1 27 30
_13:02 91 40
_13:05 90 28 50
_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