subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: Subversion 1.9.0-dev FSFS performance tests
Date Fri, 20 Jun 2014 10:33:00 GMT
On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:

> Hi,
>
> I've performed several FSFS performace tests using latest Subversion
> from trunk@r1602928.
>
> Please find results bellow. I'm also attaching results as a table in
> pdf for easier reading.
>
> Environment:
> Windows Server 2012 R2 (x64)
> 2 GB RAM, with 2 virtual processors hosted on Macbook with SSD disk
> Subversion 1.9.0-dev from trunk@r1602928
> Test data: Ruby project repository (46054 revisions, 400mb-500mb size on
> disk)
>
> All tests are performed using default options.
>
> Tests performed:
> 1. svnadmin load -- loading first 5000 revisions into repository
> 2. svnadmin dump -- dumping all repository revions to NUL
> 3. svn log http:// -- svn log over http:// protocol to NUL
> 4. svn log file:// -- svn log over file:// protocol to NUL
> 5. svn export http:// -- svn export over http:// protocol to local disk
> 6. svn export file:// -- svn export over file:// protocol to local disk
>
> Subversion 1.9.0-dev, fsfs6 unpacked repository
> ===============================================
>
..

> svn export http://   7.336      7.757    7.437
> svn export file://   4.151      4.854    4.310
>

Did you actually run the export on the repository root?
If so, those numbers are plainly impossible. Here is why:
         54,641 directories
        512,580 files
  4,558,565,078 bytes in files
      3,077,645 properties
     45,809,954 bytes in properties

There is simply no way that httpd would deliver that amount
of data in about 4 seconds! To do this requires hot caches and
20 .. 30 GHz of CPU power being used by > 10 concurrent
connections.

Also, you are basically saying that reading many small files
is more efficient than reading the same amount of user data
combined into a few larger ones. The on-disk data size alone
should make packed repos faster.

-- Stefan^2.

Mime
View raw message