https://bugs.documentfoundation.org/show_bug.cgi?id=153202
Bug ID: 153202
Summary: FILESAVE: saving .odt to a smb network drive is slow
(with excess download traffic)
Product: LibreOffice
Version: 7.4.3.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Created attachment 184901
--> https://bugs.documentfoundation.org/attachment.cgi?id=184901&action=edit
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
--
You are receiving this mail because:
You are the assignee for the bug.
