Apache OpenOffice (AOO) Bugzilla – Issue 50983
Saving document to a network drive is slow
Last modified: 2009-10-07 16:27:04 UTC
Hi, I have found that saving document to a network drive is 50% to 200% slower than to local harddisk. This is with a 100Mbs unused LAN connection to a normal windows workgroup share. For example: http://www.oasis-open.org/committees/download.php/12573/OpenDocument-v1.0-os.sxw Saving this document to a local harddisk takes 20 seconds and to a network drive 30 seconds. A document "network_save_test.odt" which is an example of vocabulary document that my nonprofit organization uses to publish technical finnish language vocabularies takes 40 seconds to save to a local harddisk and 2min 15 seconds to save to a network drive. That is over 200% more. Server: 1600 Mhz P4, WinXP Client: +2200 AthlonXP, WinXP
Created attachment 27328 [details] Local save 40s, save to a network drive 2min 15sec
Framework issue.
When using any other application or MS Explorer, saving to network volumes takes longer too than saving on local harddisk.
.
I know it takes usually more time to save to a network drive with any application, but 2 min 15 sec for a 109kb document is just too much IMHO. Even the 40 sec save to a harddisk is already quite long. I just tried it on a 100 Mbps connectien where the is no other traffic, turned off all other applications including realtime virus protection and it still takes 2min 15sec . I have no other applications that saves to a network drive even nearly this long time, even with many times larger documents. Also opening the document from a local harddisk takes 15 sec and opening from a network drive takes the same time, 15 sec. Opening the document from a network drive is no slower than opening from a harddisk. Considering there is no difference in the opening times, the save time difference is quite long. Yes I know saving is slower, but this much. Also if OO could first save the network document locally and then just copy it over the network. The save time would be only 40 sec + 1 sec instead of 2 min 15 sec. Anyway, thanks for your time. -Saku
Sorry to bother you again, but I have investigated this problem a little bit more and found out some interesting stuff. 1. By watching the system monitor I found that during the 2min 15sec saving OO takes about 2.5% from the 100 Mbps connection. Thats about (0.025 * 100 Mbps * 135s )/ 8 = 42Mb of data transferd back and forth the line. 2. Monitoring the sent and received bytes confirmed that saving the document produced Send bytes: 15 531 025 Received bytes: 18 295 856 Total: 33,8 Mb of data So saving 110 kb document creates 33,8 Mb of network traffic. 3. I also used a filemonitor to monitor filesystem activities during the save to find out what was happening. Monitoring the file revealed that apparently OO checks the state of the file about 10 000 times which shows as repetation of block of log data below int the filemonitor log file. This block repeats about 9350 times filemonitor log file. # Time Process Request Path Result Other <BLOCK> 76 11:41:20 soffice.bin:3664 OPEN T:\network_save_test.odt SUCCESS Options: Open Access: All 77 11:41:20 soffice.bin:3664 OPEN T:\ SUCCESS Options: Open Directory Access: All 78 11:41:20 soffice.bin:3664 DIRECTORY T:\ SUCCESS FileBothDirectoryInformation: network_save_test.odt 79 11:41:20 soffice.bin:3664 CLOSE T:\ SUCCESS 80 11:41:20 soffice.bin:3664 OPEN T:\ SUCCESS Options: Open Directory Access: All 81 11:41:20 soffice.bin:3664 DIRECTORY T:\ SUCCESS FileBothDirectoryInformation: network_save_test.odt 82 11:41:20 soffice.bin:3664 OPEN T:\ SUCCESS Options: Open Directory Access: All 83 11:41:20 soffice.bin:3664 DIRECTORY T:\ SUCCESS FileBothDirectoryInformation: network_save_test.odt 84 11:41:20 soffice.bin:3664 CLOSE T:\ SUCCESS 85 11:41:20 soffice.bin:3664 CLOSE T:\ SUCCESS 86 11:41:26 soffice.bin:3664 OPEN T:\ SUCCESS Options: Open Directory Access: All 87 11:41:26 soffice.bin:3664 DIRECTORY T:\ SUCCESS FileBothDirectoryInformation: network_save_test.odt 88 11:41:26 soffice.bin:3664 CLOSE T:\ SUCCESS 89 11:41:26 soffice.bin:3664 OPEN T:\network_save_test.odt\ NOT A DIRECTORY Options: Open Directory Access: All 90 11:41:26 soffice.bin:3664 OPEN T:\network_save_test.odt\ NOT A DIRECTORY Options: Open Directory Access: All 91 11:41:26 soffice.bin:3664 OPEN T:\ SUCCESS Options: Open Directory Access: All 92 11:41:26 soffice.bin:3664 DIRECTORY T:\ SUCCESS FileBothDirectoryInformation: network_save_test.odt 93 11:41:26 soffice.bin:3664 CLOSE T:\ SUCCESS 94 11:41:26 soffice.bin:3664 OPEN T:\network_save_test.odt\ NOT A DIRECTORY Options: Open Directory Access: All </BLOCK> I will attach the whole filemonitor LOG file
Created attachment 27615 [details] Log file showing filesystem activity during the save
As sseppala pointed out on dev@openoffice.org on July 6, 2005 ("Re: [dev] Saving document creates a lot of network traffic"): "I just did some testing and found out that it is the hyperlinks that make saving my 109Kb .odt document to a network drive cause 33,8 Mb of network traffic. It appears that when OO is parsing the document for saving, each hyperlink it comes across causes it to go open and close the folder of the document and the document it self several times. This of course couses lot of delay and network traffic overhead. When saving to a local harddisk this is not a big issue because delays are so short, but when saving to a network drive it becomes extremely slow if document has lots of hyperlinks." The document contains lots of internal references of the form <#IDxx>. When saving the document, this leads to lots of calls to URIHelper::normalizedMakeRelative with a baseUriReference argument of <file:///T:/network_save_test.odt/content.xml> (which is the same for all calls) and a uriReference argument of <#IDxx> (which is different for different calls). Internally in URIHelper::normalizedMakeRelative, normalizing the given baseUriReference causes the excessive network traffic (which, by the way, is to some extend a problem of SMB, which does not cache data; trying this with NFS, which caches more aggresively, shows no time differences compared to a local store). sb->mib: This issue affects load/save performance. As there is no good solution to caching the result of repeatedly normalizing <file:///T:/network_save_test.odt/content.xml> within URIHelper::normalizedMakeRelative (under what conditions should any cached data be considered stale?), how about caching the information up the call stack? That is, I could extend URIHelper with rtl::OUString normalize(rtl::OUString const & uriReference) and instead of calling URI::normalizedMakeRelative (or URI::simpleNormalizedMakeRelative) you would call some non-normalizing "makeRelative" function with pre-normalized input while saving.
Thank you very much for looking into this issue. >and instead of calling URI::normalizedMakeRelative (or >URI::simpleNormalizedMakeRelative) you would call some non-normalizing >"makeRelative" function with pre-normalized input while saving. Wouldn't this also speed up the local saving considerably by reducing filesystem calls :) .
Accepted
It's time to remove file access to make URLs relative ;-) Reassigned, target set
Fixed together with issue 100683 in cws os128 in xmloff/source/core/xmlexp.cxx
It's so nice to see this issue fixed :) . Shows that making these reporst pays off, even if it takes some time. Thanks.
Reassigned for verification
Verified in CWS os128. Saving is now extremely faster.
*** Issue 104859 has been marked as a duplicate of this issue. ***
Checked in dev300m60.