On Sat, Feb 12, 2011 at 9:48 PM, Marcus Grimm <mgr...@medcom-online.de>wrote:
> > I should've realized it wasn't running this fast but the small 5000 > record > > size got me. > > Test it yourself. > > I do have a 7200RPM drive. My 261.4 numer is still 2+X your theoretical. > > I don't want to be a smart-arse, but I still think your 261.4 is to fast. > On a 7200 RPM drive one will have 125 chances/sec to see a sector to be > written. Since sqlite, under normal journal mode, will need 3 syncs > per commit as far as I can recall, the maximum number drops further > down to 41 commit/sec. This is theoretical, in reality one will see > maybe 20 commits/sec. Not sure if a disc write-cache will interfere > with that caluclation, though. > Am I wrong ? :-) > Interesting, I did a test on a 7200 file and the best I could do was 50 commits per second (a simple base/table with only id, journalling off and no extra code since the tool I use has "a repeated query" option with accurate timing). You mentioned 3 syncs per commit, but I tried to look at the log of Process Monitor for the tool process and I saw only one entry with 'FlushBuffersFile' that is as I suppose was a mirror name for FlushFileBuffers in winSync of sqlite so probably 3 syncs was a too big an estimate, wasn't it? In this case 50 commits per second looks reasonable limit Max Vlasov _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
