Created attachment 184901 [details] Gif image showing network usage while saving to smb share Users in my non-profit organization have reported that saving large .odt documents to a windows smb network drive is slow, especially over VPN-connections. This is not a new issue, but it has become more relevat because of rise in remote working recent years. I looked into this issue and found that LO Writer generates surprisingly large volume of download traffic while saving to a windows smb network drive. For example saving document (7,5Mb): https://www.pitonyak.org/OOME_4_0.odt generates 16MB (2x file size) of download traffic and 8MB on upload traffic. Saving takes: 80 s. over 10/10Mbit VDSL 35 s. over 200/20 4G wireless. 12 s. over 1Gbit local network 8s. to local nvme drive Also the usage profile of network bandwidth is interesting, see the attached image. Right in the beginning LO creates quite rapidly 8MB of upload traffic, then a big pause (probably serializing the document), then the main upload of the file 8MB and after that it again creates rapidly another 8 megabytes of mystery download traffic. Upload traffic matches quite logically with the size of the file. However, the upload volume, which is double the file size, is little strange. I guess that is just small packets for checking file status or something. This may be specific to Windows smb network shares and may not affect NFS shares due to superior caching. If this is the case, why this caching could not be done in LibreOffice? Remote work using VPN connections has become more prevalent in the recent years, which has also made this problem more current and relevant. Users can alleviate this by downloading and working on a local copy, but IMO this not good practice for organizations. Could something be done to improve this? Reducing the excess download traffic could really help people working on large complex documents over slower internet connections. PS. 18 years ago I submitted little similar (but not same) issue for OpenOffice. https://bz.apache.org/ooo/show_bug.cgi?id=50983 Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: fi-FI (fi_FI); UI: en-GB Calc: CL threaded
Created attachment 184903 [details] Gif image showing network usage while saving to smb share I accidentally mislabeled the spikes in the original network usage chart.
I messed upload/download in the part characterising network usage, it should been said: Also the usage profile of network bandwidth is interesting, see the attached image. Right in the beginning LO creates quite rapidly 8MB of download traffic, then a big pause (probably serializing the document), then the main upload of the file 8MB and after that it again creates rapidly another 8 megabytes of mystery download traffic.
Are you sure that those are data volume, not speed? At the right of the line (I think average) shows 7.7 Mbps
(In reply to m.a.riosv from comment #3) > Are you sure that those are data volume, not speed? Yes, I'm quite confident about the figures. The data volume numbers are not from the uploaded image, they are from Windows "Network Details" view, which allows you to see the cumulative transferred bytes. I uploaded the image showing network speed as function of time, because it shows better that this excessive download activity is concentrated on the beginning and end of the saving process. I tested this multiple times with the same result and I'm sure there was no other traffic at the same time. In Windows the "Network Details" view is available from Task Manager -> Performance -> Ethernet -> right click the graph and choose "View network details" Cumulative "Bytes received/sent" are shows since the moment you opened Task Manager.
I did some more research on this issue after realizing that LibreOffice has a "Open Remote" feature, which was supposed to have a "Windows Share" option. However, on Windows installation there is no such option. Then I decided to try this on Linux. I installed Ubuntu 22.04 Desktop on VirtualBox virtualization environment on my Windows 10 Pro 22H2 system. Then I opened the previously mentioned OOME_4_0.odt file from Windows SMB share and I got the following results when saving: Saving takes: 35 s. over 10/10Mbit VDSL 30 s. over 200/20 4G wireless. Download traffic was reduced from 16MB to just 0,1MB and the upload traffic remained the same 8MB as expected. So, the overhead download traffic was reduced to just a small fraction of what it was on the Windows platform and as a result the slowest network (10/10) connection saw also a massive 56% reduction in the saving time. The much faster internet 200/20 connection saw small 14% decrease in the saving time. This result is expected because the reductions come from reduced overhead download traffic and the faster connection is already mainly limited by the LO serialization process, not the network speed. I also noticed that when opening the file from Ubuntu file manager, LibreOffice recognized this as remote file (shows (remote) on the window title) and the saving is also equally fast in that situation. As conclusion, this issue mainly affects Windows users with slow internet connections. Linux test configuration on Windows 10 Pro 22H2 Virtualbox host: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-GB Calc: CL threaded
Correction, Linux users might be also affected if the document is opened from smb share that is mounted to the main filesystem hierachy, so that LO does not treat it as a remote file. in other words, not opened from: smb://username@server/sharename/
Now I investigated this issue using Wireshark network protocol analyzer, which can capture and display packets transmitted on chosen network interface. Wireshark can also reconstruct objects that (files) have been transmitted. Using Wireshark I was able to see that Libreoffice does indeed initiate a read operation on the file in the start of the saving process and it was also able to capture the entire old version of the file being transferred on the line. I also succeeded to save this file from Wireshark and open it using LO Writer to verify that it truly was the old version of the file. Is it really the intended behaviour of LibreOffice to read the content of the old file before saving or is this this some unintended behaviour that is somehow related to the way that SMB protocol works? The network traffic also seems to indicate that LibreOffice reads the new file immediately after it has been written.
I had an idea to compare saving in the LO native .odt format to saving in the MS .docx format and the result was quite interesting: LO .odt saving OOME_4_0.odt upload: 8 MB download: 16 MB LO .docx saving OOME_4_0.docx upload: 8 MB download: 0,35 MB So when compared, .odt saving generates staggering 45X more download traffic than .docx, when saving to a SMB network drive.
The time to load the file|save and file|open dialogs on both smb and nfs mounted drives is an issue. The several seconds it takes for even a small directory to load if there is any latency is very distracting. Other applications don't have this problem.
Devseppala, it seems, that nobody could confirm this bug since more than one year. So I‘d like to ask, if it is still reproducible for you. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/current.html? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Please have also a look at bug 160215 and 160315.