Created attachment 83646 [details] table/graph of render times of different size files opened over different latency network connections If I open a PDF with okular from a file share connected over a high latency WAN connection, the render time increases to unreasonably high levels. Eg A simple 101 page 1.9MB PDF with some text and bitmap images, takes 1 minute to render on a connection with 30ms round trip latency. I did my deep testing on ubuntu 12.10 (our current desktop standard) with okular 0.15.5/poppler 0.20.4 I did a very quick verification on ubuntu 13.10 with okular 0.17.2/poppler 0.24.1 to make sure the problem was still reproducible on a more current release. It was. Test bench consisted of a client running ubuntu 12.10 connected to a machine running WANem to simulate WAN latency (no bandwidth throttling in place, only latency was changed). A samba server sat on the other side of the WANem router, and the ubuntu client connected via mount.cifs I opened two files from the samba share, a 1.9MB PDF with text and bitmap pictures, and a 10KB PDF file with text. I timed the length of time to do the "initial load" (blank pages), and the time for the final render, increasing the latency after each set of tests from none, up to 50ms. I also timed a straight file copy using 'time cp remotesrc localdest'. Units are in seconds unless specified. Okular performance was set to "Greedy". Results are in the attached spreadsheet - as you can see the render time increases linearly with latency, in all cases the 1.9MB file is ~10x slower to open than the 10KB file, regardless of latency. The peak render time was 1:38s for a 1.9MB file over a connection with 50ms latency. Equivalent render times over the same connection: Acrobat Reader, same 1.9MB PDF: ~6s Okular with 1.9MB TIFF file: ~6s In a practical sense, here's what it means for me: The company I work for runs ~170 KDE desktops at 9 sites around Australia. Our company file servers are located centrally at the head office. Our furthest branch is located in Perth, and connects back to our Head Office near Griffith NSW (~3500kms). The round trip latency to this site is ~70ms. Our lowest latency site is Sydney, with a round trip latency of ~16ms. The other sites range in between. In summary, we have larger files, and higher latency to some of our branches than measured. Load times are already unacceptably high under my very modest testing conditions. What else can I do to help get this issue resolved?
I have done some more testing this afternoon, mounting a share via nfs and opening the same files over a link with 50ms latency is near instant. So I can confirm the issue is with cifs only (knowing cifs to be a particularly chatty protocol, this comes as no surprise). I did a wireshark capture during the open time of the 1.9MB file to quantify the difference between the two protocols: CIFS/SMB: 3155 SMB packets captured (of 6433 total) NFS: 12 NFS packets captured (of 25 total) While this narrows the issue down, I still think this is a bug that needs resolution from this side. CIFS/SMB is a very common protocol, particularly on windows, and particularly given the KDE on Windows project (which I've tried again recently, and found really handy!).
how are you opening the file? okular smb://some/path? Or you have the fs mounted and then just do okular /some/path/that/is/really/not/local ?
Hi Albert, I'm using the method: okular /some/path/that/is/really/not/local
Can you try the speed of okular smb://some/path? I have not tried but that should give you better speeds. But i understand that may not be feasible to change your way of working, no?
Running that actual command from the commandline didn't work, but I pointed dolphin at smb://server/share/ and grabbed the file via that method (using the kio/fuse type mount, as opposed to mount.cifs) It fully rendered the PDF in about 3 seconds.
(In reply to comment #5) > Running that actual command from the commandline didn't work Didn't work? That's bad, should have worked, did it give you any specific error? > , but I pointed > dolphin at smb://server/share/ and grabbed the file via that method (using > the kio/fuse type mount, as opposed to mount.cifs) > > It fully rendered the PDF in about 3 seconds. Yeah, as said that'd be faster, now the question is if this is a reasonable workaround for you :D
Heh, ok the files I'm grabbing are from a tmp directory and the 1.9MB file I was trying to open got cleaned up over night. The smb://server/share/file.pdf from cli *does* work with same results as from the dolphin/kio pointing to smb://server/share This is not an adequate workaround at this point - in our experience the kio/fuse mounting methods have been a bit unpredictable when it comes to file locking, which is why we use the mount.cifs method. Having said that, I haven't done a full suite of kio/fuse file locking testing in a while so I should do that as well, but if it works it will require a lot of backend process modification for various bits and pieces. Even then, I'm still months out from being able to get that cleaned up tested in production. On top of that, the timeframe coincides with a critical period of our business (vintage harvest) in which we as an IT dept simply can't make major changes in the business. Vintage lasts 3-4 months and that puts us 6 months out from a fix - if it even works. If you are able to provide a local caching method for cifs (or non-local) filesystems in okular, that would be my heavy preference for a quicker, easier, less intrusive resolution.
Can you compile/run this program and run it doing ./binary /path/where/my/not/really/local/file/lives and tell me what it returns?
Created attachment 83669 [details] main.cpp
Created attachment 83670 [details] foo.pro
compiling should be a matter of qmake && make if you have kdelibs in /usr/lib
Sorry for the slow response - fielding calls. The output: ~$ ./foo /network/3tales/scratch/dion/3.7mb.pdf "/network/3tales/scratch" "cifs" false
Ok, so the only thing i can think of to solve this is copying the file locally to a temp folder and then opening that, but need to find out how to properly do it. It's not as trivial as it sounds
That was my understanding about the best way to resolve too - In terms of impact on us, it's affecting a lot of our users (about 1/3 are remote). I can have a chat to my manager about donation/payment incentives to assist with getting the work done if that would help?
It's not about money/time, though a donation is always welcome :-) It's more about "how to do it right"
What would be actually useful is if you could provide us with some kind of environment (not your production one, but a "fake/test" one) so we could test this problem plus the solution ourselves. Do you think that's doable?
I should be able to setup a little external testbench, what sort of access would you need? would SSH plus something like teamviewer be enough? I'll confirm when I get to work this morning -
Actually i was thinking of a australian-based samba server i could cifs mount. Not more than that, i.e. i can use my local okular to connect to the other side of the world and i guess it'll show the same problems you're having
Back to need info, we were having conversations on email in me trying to reproduce the setup but i could never succeed in reproducing it
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!