Very slow PDF loading

[Christian Gruber]

Hi, 

the loading and rendering of PDF files is very slow on our production server. For example, a 7kB big PDF (https://www.dropbox.com/s/cnexe8bmx3xhz4g/testpdf.pdf?dl=0) takes more than 8 seconds to display. On our Dev-server using the same code it loads instantly. 

Here the loading of a file from Chrome developer tools is shown:

As visible, PDFNETCFull.js.mem needs about 6 seconds to start, although the PDF file was received from the server already. The WebViewer files are also cached so this won't be the issue. 

The JS console writes: 

HTTP range requests not supported. Switching to streaming mode.

CoreControls.js:669 Could not use incremental download for url https://rothkopf.ipdoc.com/alfresco//download/attach/workspace/SpacesStore//bceaf358-808a-4592-b1a4-33a9882330f7/2016-11-17_16-23_[HUHUHUHUH] [FAMHUHU] [Inbox] testpdf(1).pdf?ticket=TICKET_69ea1b569c9dd71c3530764465b1e10cc8b7962b. Reason: The file is not linearized. 

VM37:1 PDFNet is running in demo mode.

VM37:1 Permission: read

VM37:1 Permission: write

VM37:1 Permission: rast

This is also strange, because the output "PDFNet is running in demo mode." and the outputs for the permission checks are not made when running on our Dev. server. When I look at the output initiator i see that it is coming from debugger://. But can this be an issue? As said, the same file loads fast from the other server, so linearization won't be the issue. 

Thanks for your help!

Edit: Additional info

- The issue occurs with Chrome as well as Firefox

-  The files from our production server are loaded via HTTPS while HTTP is used on the Dev. server

[Matt Parizeau]

Hi Christian,

A little background on how PDFNetJS renders files is that on Chrome it uses the PNaCl technology (which is only supported by Chrome, but is very fast) however it has upfront extra compilation time the very first time it loads. Once it has finished compiling it's very fast. Other browsers use Emscripten which is generally a bit slower but it works in every browser. For Chrome by default we check to see if PNaCl has compiled and if not we load it in the background and fallback to using Emscripten. So what may be happening on Chrome is that it hasn't compiled PNaCl yet so it's falling back to Emscripten, which according to your network screenshot appears to be what's happening. On less powerful machines this may be causing the extra delay, but we're not 100% sure.

One thing you could try is setting the pdfBackend option in your WebViewer constructor to force it to use a particular technology. So you could set pdfBackend: "pnacl" and you'll see that there's an initial loading bar before it renders the document but if you refresh after the loading bar is complete you'll see that it loads very fast. Once PNaCl is loaded you could remove the pdfBackend option and see if the problem still occurs with the delay in loading. You could also try setting pdfBackend: "ems" which will use Emscripten and see if the delay occurs when only loading the Emscripten version.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Christian Gruber]

But wait, why do I get very fast loading on Firefox when visiting https://www.pdftron.com/webviewer/showcase/ ?

[Christian Gruber]

Hi Matt, 

thanks for the detailed response! This seems to be the issue. I guess PDFNetJS was compiled in background while development so I always got fast loading times when using our dev. server. When testing on the production server it never could finish to compile so I thought it has to be something with the back-end. When forcing PNaCl I also get fast loading on our production server, when forcing Emscripten I also get slow loading on the dev. server. 

Actually, we need very fast loading times on Firefox as well. I have to find out if this is a problem now. 

Where is the compiled PNaCl version stored? I cleared all application cache but it seemed to be still existing (very fast loading after clearing complete site/application cache). For how long is it cached/stored? 

Thanks for your help!

Christian Gruber

[Matt Parizeau]

Hi Christian,

I'm not sure where the compiled PNaCl version is stored, probably where other cached data is stored for Chrome. I tried clearing the cache by going to "Clear browsing data" in Chrome and only checking "Cached images and files". After doing this when I refreshed I got the document loading bar to appear which means it was cleared from the cache. It should be stored as long as Chrome decides to keep the cached data which I think is usually until the user deletes it explicitly. Do you see the document loading bar the first time you load a document with the pdfBackend option set to "pnacl"?

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Christian Gruber]

"Do you see the document loading bar the first time you load a document with the pdfBackend option set to "pnacl"?"

Yes. This works well on Chrome and it's also very fast. Chrome isn't an issue anymore. 

FYI: The response "But wait, why do I get very fast loading on Firefox when visiting https://www.pdftron.com/webviewer/showcase/" was made after my longer response. 

This is still an issue. While I understand that PNaCl doesn't work on Firefox, I don't understand why I get fast loading (with Firefox) at your showcase but not on my application. All files are served within milliseconds, so that can't be the issue. I always see a loading bar "Loading document: 100%" that stays for ~5 seconds.

I also ask myself when the "debug mode" is activated? The mode that prints out the stuff regarding license, permissions etc. Every time I see that output the loading is very slow. And I don't see that mode when visiting your showcase. 

Thanks, 

Christian

[Matt Parizeau]

Hi Christian,

On the main page of the showcase those are all XOD files which is why nothing about the license is being printed. If you click the tab "Your Files" and then the "Open PDF" button you'll see the viewer with PDFNetJS and in you'll see the logs in the console.

We don't expect Firefox with Emscripten to be that much slower than PNaCl. Would you be able to send the file that you're loading?

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Christian Gruber]

Hi Matt, 

I just e-mailed the login information for our system to your colleagues and support [ at ] pdftron

Best regards

[alextrs]

Hi,

Were you able to figure out what is going on? I have very similar problem (ver 2.2.1), when try to open PDF it takes 5-15 seconds and in processes I see nacl64 that takes a lot of CPU (every time I refresh browser). Chrome 54.0.2840.99.

In my case I see this same problem with showcase too (when in PDF mode).

Regards,
Aliaks

[Matt Parizeau]

Hi Aliaks,

Here's the explanation I shared earlier in this thread about what's going on behind the scenes when you load up a document with PDFNetJS. 

A little background on how PDFNetJS renders files is that on Chrome it uses the PNaCl technology (which is only supported by Chrome, but is very fast) however it has upfront extra compilation time the very first time it loads. Once it has finished compiling it's very fast. 

If you wait long enough for it to finish compiling then nacl64 shouldn't take as much CPU on subsequent refreshes.

One thing you could try is to have PNaCl use the new Subzero compiler (https://github.com/stichnot/subzero) which is much faster initially at slight decrease in overall performance. You can do this by finding lib/html5/pdf/PDFWorker.nmf and making a small modification, changing it to this:

{
  "program": {
    "portable": {
      "pnacl-translate": {
        "url": "PDFWorker.pexe",
        "optlevel": 0
      }
    }
  }
}

After this try loading a PDF document and see if this improves things for you. We're currently investigating using this with WebViewer or including options to toggle it on or off.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Christian Gruber]

Hi, 

in our case it helped a lot to use the "lean" WebViewer instead of the "full" one. 

Greets