Issue 4502: FSFS f6 ./. f7 performance

[Stefan Fuhrmann <st...@wandisco.com>]

Here the results of my measurements taken over the last
couple of days.

Summary:

null-export of source code from spinning disk, NTFS Linux:
* packed f6 4x as fast as non-packed f6
* packed f7 20x as fast as non-packed f7
* packed f7 4x as fast as than packed f6
* non-packed f6 1.4x as fast as non-packed f7
-> you want f7 and you want packing

null-log -v -g from spinning disk, NTFS Linux:
* packed f7 6x as fast as packed f6
(non-packed not measured; very likely similar factors as above)

null-export of source code from spinning disk, NTFS Windows:
* packed f7 2.5x as fast as packed f6
  (limited by USB2)

Setup details:

Repository: freebsd-base, r264989 (almost worst case
of non-packed latest shard in packed repositories), ~3GB,
dirs deltified.

Server: svnserve 4G (Linux) / 1G (Windows) cache,
-c 0, revprops cached

Disk: USB3 spinning disk, NTFS format. Windows tests
ran over USB2 limiting throughput to about 1/3.
A thunderbolt SSD was used to determine the impact
of I/O latency (Linux only).

All measurements done in a "cold setup" using svn-bench.
null-export produced
          6,199 directories
         58,000 files
    782,836,361 bytes in files
        326,397 properties
      4,877,614 bytes in properties

null-log -v -g produced
        185,096 revisions,             528 merged in 823 merges
        994,976 msg lines,           3,347 in merged revisions
      1,109,675 changes,           115,618 in merged revisions

Detailed results:

null-export, USB3 HDD, fuse NTFS, Linux
F6 packed    616s
F7 packed    176s
F7 nonpacked   3495s
F6 nonpacked   2546s

null-export, same HDD over USB2, NTFS, Windows
F6 packed    834s
F7 packed    342s
(both were throughput limited)

null-export, Thunderbold SSD, fuse NTFS, Linux
F6 packed    24.2s
F7 packed    18.8s
F6 nonpacked    21.3s
F7 nonpacked    34.7s
(non-packed operation is latency limited on HDD)

null-log, USB3 HDD, fuse NTFS, Linux
F6 packed    809.101s
F7 packed    134.636s

null-log, Thunderbold SSD, fuse NTFS, Linux
F6 packed    211.097s
F7 packed     23.436s
(operation is latency limited on HDD)

Re: Issue 4502: FSFS f6 ./. f7 performance

[Ivan Zhakov <iv...@visualsvn.com>]

On 19 June 2014 12:01, Stefan Fuhrmann <st...@wandisco.com> wrote:
> Here the results of my measurements taken over the last
> couple of days.
>
> Summary:
>
> null-export of source code from spinning disk, NTFS Linux:
> * packed f6 4x as fast as non-packed f6
> * packed f7 20x as fast as non-packed f7
> * packed f7 4x as fast as than packed f6
> * non-packed f6 1.4x as fast as non-packed f7
> -> you want f7 and you want packing
>
> null-log -v -g from spinning disk, NTFS Linux:
> * packed f7 6x as fast as packed f6
> (non-packed not measured; very likely similar factors as above)
>
> null-export of source code from spinning disk, NTFS Windows:
> * packed f7 2.5x as fast as packed f6
>   (limited by USB2)
>
> Setup details:
>
> Repository: freebsd-base, r264989 (almost worst case
> of non-packed latest shard in packed repositories), ~3GB,
> dirs deltified.
>
> Server: svnserve 4G (Linux) / 1G (Windows) cache,
> -c 0, revprops cached

Am I understand properly that all your performance tests are performed
for svnserve only and with enormous cache size?

Have you performed any tests for HTTP servers? Have you performed any
tests with default cache size (that most of the users have)?

It is unusual to have a 4GB cache for 3GB repository. Such amount of
memory could be not available for cloud-based subversion hosting
providers, for example.

With the default 16Mb cache I have quite duifferent results shown in
the [1]. My tests show that FSFS7 could be 2-10 times slower that
FSFS6 in the default configurations.

[1] http://svn.haxx.se/dev/archive-2014-06/0065.shtml

-- 
Ivan Zhakov