Benchmarks for PUT for various fsfs config settings.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3
Chart:


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Benchmarks for PUT for various fsfs config settings.

Markus Schaber
In reply to this post by Paul Hammant-3

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:
[hidden email] | 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:[hidden email]]
Sent: Tuesday, August 01, 2017 9:05 AM
To: Subversion Development
Subject: Benchmarks for PUT for various fsfs config settings.

 

Chart:

 

 

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Johan Corveleyn-3
In reply to this post by Paul Hammant-3
On Tue, Aug 1, 2017 at 5:36 AM, Paul Hammant <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3
In reply to this post by Markus Schaber
I'll re-run for smaller sizes (and yes that 128GB was a typo)

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

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


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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: [hidden email] | 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:[hidden email]]
Sent: Wednesday, August 02, 2017 3:28 PM
To: Markus Schaber
Cc: Subversion Development
Subject: Re: Benchmarks for PUT for various fsfs config settings.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Benchmarks for PUT for various fsfs config settings.

Paul Hammant-3

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
Loading...