97
edits
| Line 157: | Line 157: | ||
[[File:Watson-100iter-128byte-telemetry-nocache.png|800px]] | [[File:Watson-100iter-128byte-telemetry-nocache.png|800px]] | ||
This is from another run on the Linux server, including results for using full caches. The first graph shows "misses", i.e. it indicates time to search the cache for each resource, clear space for it, load it and finally set it up for saving to the cache. Loading resources with cache disabled is included first as a reference. | |||
[[Image:Watson-summary-misses-100iter.png|800px]] | |||
The second graph shows the hits, i.e. time when each resource is found in the cache. '''Note that no shuffling of the entries in the cache is done prior to measuring this - all 100 entries are nicely placed in sequence as the least recently used elements loaded in the previous test''' Loading resources with cache disabled is included first as a reference. | |||
[[Image:Watson-summary-hits-100iter.png|800px]] | |||
By studying the two latter graphs a few points seems to require further investigation | |||
; miss / mem-cache full of small entries: seems to perform really bad for large resources (surprising, because I'd expect the disk-cache to always be slower) | |||
; miss / disk-cache full of small entries: performs clearly worse than the empty disk-cache for small resources (not surprising, but we may want to try optimizing this somewhow) | |||
; hit / mem-cache full of small entries: seems to perform really bad for 2k and 8k resources (can be reproduced in subsequent runs) - could it be the access-pattern? | |||
=== test_timing_cache.js '''(Obsolete)''' === | === test_timing_cache.js '''(Obsolete)''' === | ||
edits