On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <i...@visualsvn.com> wrote:
> On 19 June 2014 14:21, Ivan Zhakov <i...@visualsvn.com> wrote: > > Hi, > > > > I've performed several FSFS performace tests using latest Subversion > > from trunk@r1602928. > > > I've re-ran my FSFS performance tests with trunk@r1605444 using latest > fsfs7 performance fixes including combining indexes to revision files. > Makes sense, that's close enough to what I used as a basis last week. Optimizations since then have mostly brought down the CPU overhead when reading from SSD, RAM disk or disk cache. > This time I used the same Windows VM hosted on Macbook with SSD disk. > Haven't looked at the results there, yet. > Also I run the same tests on Windows VM on typical IBM x3620 M3 server > with SAS raid attached spinning disks on Windows Hyper-V: this is very > typical configuration in SMB environment. > Yes, that is certainly a typical configuration. > Please find results in attached pdf for easier reading. I leave making > conclusions to readers. > Could you re-run the dump tests with -r0:5000 as you did two weeks ago. Otherwise, it will be hard to check the results for plausibility (I don't have access to my server hardware for the next 3 months or so). Also, it seems that some of these tests are run from hot caches - causing a lot of variation and making comparison pointless. An extreme case: ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/ Copyright(C) 2002, Jem Berkes <jber...@pc-tools.net> === "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" === Execution time: 216.064 s ... Execution time: 13.268 s ... Execution time: 18.061 s I'm not pretending that my performance tests are scientific, but my > goal is just to validate that fsfs7 is not worse than fsfs6. > That's a good goal. I'm currently through with my FSFS TODO, except for documentation and committing a change you suggested in Berlin. I'll then write a post on the pitfalls of repo performance testing (plus a script to avoid them). Furthermore, I'll convert the raw measurement data (plus additional tests run later) into something easier to consume. -- Stefan^2.
