Apache OpenOffice (AOO) Bugzilla – Issue 77281
svn: performance problem when during commit
Last modified: 2009-07-12 18:27:16 UTC
There are two test scenarios: (1) add a new directory with 165 files (4.2 MB) and commit them and (2) add a single line in one file and commit that file. for CVS on the main site we have: (1) 77 sec (2) 4.8 sec for svn on the main site we have (direct access without proxy): (1) 198 sec (2) 9.3 sec for svn on the main site and using a proxy server we have (1) 289 sec (2) 9.4 sec (this was measured during the weekend where the proxy is idle) (1) n/a (2) 14 sec (measured during regular German business hours) svn commit performance is at least factor 2 slower than cvs, I consider this as a regression and a blocker for a transition to svn. svn performance seem to be dependent from the load of the used proxy, do you have advise about a recommended proxy set up ?
Hi, Thank you for contacting CollabNet Customer Support. Based on the information that has been provided to us, we will initiate our research & provide you an update as soon as we have adequate information. Thanks, Pritha Support Operations.
I have few questions : 1) What is the proxy server setup been used for these testing . 2) Since the svn commit transaction use the same port as in the normal web traffic.Please provide us information whether this testing was done in the office network or home network . 4)Also details on whether there is any restriction on the traffic allowed from the office network/home network would be most useful in our investigation.
Updating whiteboard.
>2) Since the svn commit transaction use the same port as in the normal web >traffic.Please provide us information whether this testing was done in the >office network or home network . testing was done in office network (34 MBit line) and home office (2MBit DSL line) ; the measurements done in both networks were almost identical. >4)Also details on whether there is any restriction on the traffic allowed from >the office network/home network would be most useful in our investigation. both boxes used a natting firewall
Mh , In Theory for 'commit' itself svn may perform exceptionally well for certain cases (svn commit of hugefile with small change). Having said that Subversion has certain overheads like more HTTP connections from the client to server to do one logical svn command. Spooling the data to temporary area prior to sending the data to server(due to neon), Compressing the data etc. However we are still actively investigating on this and looking at various options were we might consistently reproduce similar slowness in comparison to the cvs commits .
Given below is some testing perform by our engineers : We tried adding 170 1MB (all 'a's in it) files for cvs and svn Without -z9 compression : CVS ------- real 1m38.753s user 0m0.895s sys 0m1.585s SVN ------- real 2m19.443s user 0m16.768s sys 0m3.868s Later we perform testing taking into consideration the 'client compression' factor as CVS by default has no compression unless invoked with -z9. However SVN by default has zlib compression With -z9 compression factor : CVS --------------- real 2m39.754s user 0m7.572s sys 0m0.620s SVN --------------- real 1m5.367s user 0m15.329s sys 0m3.613s This inconsistent result though the second one in favor of svn suggests that '-z9' could be making a difference. I assume these test were performed with the cvs -z9 compression factor. Please note in theory subversion is faster for commits. In practice it may be slow for some datasets/usage patterns. We need a solid repeatable case so that we can at-least justify the behavior if not change it. -Jobin.
for the test with CVS we're using a ssh tunnel with CompressionLevel 3, the cvs client itself is usually called without any compression switch (-z x). you're right, if additionally starting the cvs client with high compression, the times rise, but I think this is not relevant in this comparison.
1) What is the proxy server setup been used for these testing Squid Cache: Version 2.6.STABLE6 At current state i could not found any exeptional entries, which may cause the latency.
Created attachment 45316 [details] sources used for initial add/commit
Created attachment 45317 [details] script to add a new line to all files, and measure time for commit
Since this project has been on hold for quite some time. I am marking this issue as Resolved Remind for now until such time the project receives more traction.
CollabNet Support is currently reviewing the issues under Resolved-Later/Remind.
Marking as Invalid as of now
invalid -> closed