Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

http://imgur.com/a/vVKSx

This one is the original 128MB PUT test but on a Raspberry Pi Zero W
(client and server). Raspbian is based on Debian Jesse which uses Svn
1.8.10. The Zero has 512MB RAM and a 1Ghz ARM chip (the same spec as the
original Pi).  Performance was 1/6 of the CHUWI HiBox Smart Mini PC 4GB RAM
w/ a Quad Core Intel x5-Z8350 (used at the start of this thread).

Compression makes no difference here. The only differentiator is Rep
Sharing on the second and subsequent PUT (25% saving or cost, dep. on POV).
Well that and Svn 1.9.5 vs 1.8.10.

This setup would be good for documents, and music files, but not movies - I
don't know where it will crap out, butI suspect that it will. Apache has
timeouts after all. *And don't we all have war stories about timeouts and
hops!*

- Paul

Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

Markus,

Yes, leaving rep sharing enabled is better for another reason that a file
sync agent is *likely* to encounter: someone renames a directory. Remember
I'm not using Subversion client tools to effect a commit.

But...

>. Rep sharing brings its real benefits when equal files are stored
> independently on the server, while deltification is best for small changes
> in the same file (or "historically related).
>

If I were storing a CinemaDNG (RAW) movie in Subversion and my operation
was to cut one second from the movie, then I might expect deltification to
help.  It the format were MP4/AVI (H.264), I struggle to believe that the
'saving' of the movie from the editor you performed the clip in is anything
close to idempotent. I could try to find out for sure, but it's a stretch.

-ph

RE: Benchmarks for PUT for various fsfs config settings.

[Markus Schaber]

Hi, Paul,

> Here it is - http://imgur.com/a/vBeKi  - a more interesting graph.

Yes, more interesting. :-)

And it somehow supports my point that, in some use cases, switching of 
deltification and rep sharing do no good.

The benefit of disabling compression is understandable, as it just wastes CPU 
on non-compressible data.

Disabling everything seems not the fastest way this time (while it skips all 
the processing, it has to write the whole file every time), while rep sharing 
and deltification can compensate the CPU overhead with writing just a few bytes 
at the end. I expect the difference to be bigger when the CPU is faster and I/O 
is slower.


> Server side Storage Used (MB):

> Default: 129
> No_Compression_No_Deltification: 257
> No_Deltification_No_Rep_Sharing: 513
> No_Compression_No_Deltification_No_Rep_Sharing: 513
> No_Rep_Sharing: 129
> No_Compression: 129
> No_Compression_No_Rep_Sharing: 129
> No_Deltification: 257

This is also pretty much what I expected. 

Deltification and rep sharing almost compensate each other in this case (as 
we're modifying the same file). Rep sharing brings its real benefits when equal 
files are stored independently on the server, while deltification is best for 
small changes in the same file (or "historically related).


Thanks a lot!

Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH 

Inspiring Automation Solutions 

3S-Smart Software Solutions GmbH 
Dipl.-Inf. Markus Schaber | Product Development Core Technology 
Memminger Str. 151 | 87439 Kempten | Germany 
Tel. +49-831-54031-979 | Fax +49-831-54031-50 

E-Mail: m.scha...@codesys.com | Web: codesys.com | CODESYS store: 
store.codesys.com 
CODESYS forum: forum.codesys.com 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915 

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorised copying, disclosure 
or distribution of the material in this e-mail is strictly forbidden. 
From: Paul Hammant [mailto:p...@hammant.org] 
Sent: Wednesday, August 02, 2017 3:28 PM
To: Markus Schaber
Cc: Subversion Development
Subject: Re: Benchmarks for PUT for various fsfs config settings.

Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

>
>
> Here it is - http://imgur.com/a/vBeKi  - a more interesting graph.
>

Note that was 4 iterations, not 6 (as before).

Server side Storage Used (MB):


Default: 129
No_Compression_No_Deltification: 257
No_Deltification_No_Rep_Sharing: 513
No_Compression_No_Deltification_No_Rep_Sharing: 513
No_Rep_Sharing: 129
No_Compression: 129
No_Compression_No_Rep_Sharing: 129
No_Deltification: 257


- Paul

Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

>
> Next up - larger files where the second has a mid-section that changes for
> a few bytes, vs the first.
>

Here it is - http://imgur.com/a/vBeKi  - a more interesting graph.

Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

Alternate file sizes - still pretty much every byte different between the
two alternately uploaded files:

24MB - http://imgur.com/a/kPyY8
4MB - http://imgur.com/a/uRaW8

Next up - larger files where the second has a mid-section that changes for
a few bytes, vs the first.

Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

I'll re-run for smaller sizes (and yes that 128GB was a typo)

Things won't be not so separable that way, IIRC.

Re: Benchmarks for PUT for various fsfs config settings.

[Johan Corveleyn]

On Tue, Aug 1, 2017 at 5:36 AM, Paul Hammant  wrote:
> Chart:
>
> http://imgur.com/cKe2l4J
>
> In Python I made two 128GB random files, then uploaded them alternately six
> ties three each to the same endpoint in Svn over DAV.  That would be a run.
> After wiping the server repo and repeating that, I performed four runs all
> in all. For each datapoint, I took the quickest time.
>
> Settings that were part of the benchmark, compression off (0) versus
> compression as default. delticication off versus default, and rep-sharing on
> versus off.
>
> Conclusion for my intended Svn use (biiig binary files):
>
> 1. compression off
> 2. deltification off
> 3. all else default

Interesting. Thanks for sharing!

There seems to be some typo: the chart mentions 128 MB, but your mail
says 128 GB. I suppose it's MB and the times on the chart are in
seconds?

-- 
Johan

RE: Benchmarks for PUT for various fsfs config settings.

[Markus Schaber]

Hi, Paul,

Just out of curiosity: Do you have benchmarks when just a few bytes of the 
binary files change (this could e. G. reflect a JPEG EXIF data edit, or tagging 
MP3 files with author and title)?

Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.scha...@codesys.com<mailto:m.scha...@codesys.com> | Web: 
codesys.com<http://www.codesys.com> | CODESYS store: 
store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
From: Paul Hammant [mailto:p...@hammant.org]
Sent: Tuesday, August 01, 2017 9:05 AM
To: Subversion Development
Subject: Benchmarks for PUT for various fsfs config settings.

Chart:

http://imgur.com/cKe2l4J

In Python I made two 128GB random files, then uploaded them alternately six 
ties three each to the same endpoint in Svn over DAV.  That would be a run. 
After wiping the server repo and repeating that, I performed four runs all in 
all. For each datapoint, I took the quickest time.

Settings that were part of the benchmark, compression off (0) versus 
compression as default. delticication off versus default, and rep-sharing on 
versus off.

Conclusion for my intended Svn use (biiig binary files):

1. compression off
2. deltification off
3. all else default

- Paul

Re: Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

If I can manage to build the LZW compression version of the forthcoming
v1.11 Subversion, I'll put that in the mix as a permutation to test.

Is anyone interested in the Python harness for these integration tests?

- Paul

Benchmarks for PUT for various fsfs config settings.

[Paul Hammant]

Chart:

http://imgur.com/cKe2l4J

In Python I made two 128GB random files, then uploaded them alternately six
ties three each to the same endpoint in Svn over DAV.  That would be a run.
After wiping the server repo and repeating that, I performed four runs all
in all. For each datapoint, I took the quickest time.

Settings that were part of the benchmark, compression off (0) versus
compression as default. delticication off versus default, and rep-sharing
on versus off.

Conclusion for my intended Svn use (biiig binary files):

1. compression off
2. deltification off
3. all else default

- Paul