The cache simulation seems good enough to be useful now,
although the toy app I wrote to generate a 500MB trace file doesn't use MVCC in an essential way (some of the MVCC simulation code is nevertheless exercised, since an invalidation of current data in the presence of MVCC always creates a cache record for the newly non-current revision). Still puzzling over what to do when the trace file records a load hit but the simulated cache gets a miss. The old simulation code seemed to assume that a store for the same oid would show up in the trace file next, and it could get the info it needed about the missing object from the store trace. But that isn't true: precisely because the load was a hit in the trace file, the object isn't going to be stored again "soon" in the trace file. Here are some actual-vs-simulated hit rate results, for a 20MB cache, with a trace file covering about 9 million loads, over 3 ZEO client (re)starts: actual simulated ------ --------- 93.1 92.7 79.8 79.0 68.0 69.1 81.4 81.1 overall Since the simulated hit rates are both higher and lower than the actual hit rates, that argues against a gross systematic bias in the simulation (although there may be several systematic biases in opposite directions).
Showing
Please register or sign in to comment