Reply to thread

Yep, that does the trick... For now let's just to ReadTest 2.


Stop MP2 Server, Flush Read Cache, Start MP2 Server (locking_mode=Exclusive / Shared Cache / Page Size 4KB), Start MP2 Client.

ReadTest 2 (only ReadTime): 888ms, 204ms

So the first read is MUCH slower now without windows read cache.


Stop MP2 Server, Flush Read Cache, Start MP2 Server (locking_mode=Exclusive / Shared Cache / Page Size 4KB), Start MP2 Client.

ReadTest 2 (only ReadTime): 858ms, 202ms

Same test procedure, more or less the same result.


Stop MP2 Server, DO NOT Flush Read Cache, Start MP2 Server (locking_mode=Exclusive / Shared Cache / Page Size 4KB), Start MP2 Client.

ReadTest 2 (only ReadTime): 240ms, 182ms

Just to prove I was right - same procedure but without flushing the read cache - only restarting MP2 Server - and the first read time is MUCH faster - caused by the windows read cache. Second pass is also faster (don't know why, because even with flushing the read cache, after executing the query for the first time, the file should be in windows read cache and the result set should be in SQLiteCache. Maybe because ReadTest 2 is automatically executed twice with only a few ms between the tests and this may be to fast for the windows read cache...)


Stop MP2 Server, DO NOT Flush Read Cache, Start MP2 Server (locking_mode=Exclusive / Shared Cache / Page Size 4KB), Start MP2 Client.

ReadTest 2 (only ReadTime): 263ms, 195ms

Same test, more or less the same result. Second pass this time is closer to the test results with flushing windows read cache...


Stop MP2 Server, Flush Read Cache, Start MP2 Server (locking_mode=Exclusive / Shared Cache / Page Size 4KB), Start MP2 Client.

ReadTest 2 (only ReadTime): 854ms, 191ms

A last time with flushing os cache between restart and we are back to the much slower results from above.


And now another interesting test and result: From the last test, I left the MP2 Server running and flushed the windows os cache while the MP2 Server was running and then did the same test again:

ReadTest 2 (only ReadTime): 212ms, 208ms

That means that the SQLiteCache is actually working very good because when running the test for a second time while the server is running SQLite doesn't care about the windows os read cache being flushed. So it seems we have nearly all we need in the SQLite cache and don't go back to the disk/windows os cache very often.


Once again: Leave the MP2 Server running, flush windows OS read cache, start MP2 Client:

ReadTest 2 (only ReadTime): 213ms, 199ms

Same as above, the flushing of OS read cache does not affect our SQLite speed.


So what conclusion can we take from these results:

  • First of all, when we do not have any cache (i.e. restart MP2 Server to cleat SQLite cache AND flush OS cache), the results are 888ms, 858ms, 854ms. The average of this is 867ms with a deviation between +2.4% and -1.5%. I would consider this as identical results. The deviation is probably caused by other background activity. These results are consistent, but they are unrealistic. No one manually flushes its OS cache. These results are only realistic, if someone freshly restarts its MP2 Server and then enters the audio section in MP2 Client for the first time after the restart. For anything after that - be it just exiting and reentering the audio section or even after a restart of MP2 Server service, the real results will be much better.
  • When we can only rely on the Windows OS cache - but not the SQLite cache (i.e. after restarting the MP2 Server but without flushing the OS cache), we get 240ms, 263ms. The average is 251.5ms with a deviation of +/- 4.5%. Also quite consistent results - but only realistic after a restart of MP2 Server service.
  • When both caches kick in, we get 204ms, 202ms, 182ms, 195ms, 191ms, 208ms, 199ms. That's an average of 197,3ms with a deviation from +5.4% to -8.8%. These results are probably the most realistic ones - but we have the biggest deviation.

The only thing I can propose here is the following: We could just ignore the respective first test result to make sure, that both caches are up and running. This gives us the most realistic results when using MP2 "normally". On the other hand we have to say that anything +/- about 10% is not an improvement but coincidence. I think this makes sense because I'm not looking for +3% speed improvements that would probably not be noticed by anyone. I'm looking for +20%, +30% and +50% speed improvements - if possible.


So what I would do in the following for ReadTests is:

  • Start the MP2 Server
  • Leave the MP2 Server running all the time while I do the ReadTests.
  • Do every Read Test three times.
  • Discard the first result of each ReadTest and only show the second and third result.
  • For ReadTest2 (which is automatically executed twice), I would discard result 1 and 2 and display result 3 and 4.
  • I would probably leave out the QueryTime in the future because this is really taking a lot of time to get it together and I think at this stage it doesn't really bring much more valuable information.

So if anyone out there has reasons for not doing so, please speak up loud now :D


Top Bottom