Performance with GroupDocs

Hello,

When viewing large PDF files with PreloadPagesCount(1), the viewer will display the first page. However, when trying to perform page rotation, it won't rotate until all pages are loaded. There is a long delay when the file is big. Is there a way to not wait?

Also, is there a way to cancel the loading of a large file? Our application gives users abilities to pick a file to view. The user can click on a new file, but viewer was still loading the previous file, giving user the impression that the application is not working.

Thank you,

Hello,


Thank you for your request. The ultimate way to increase overall performance is an ahead-of-time (AOT) caching. With this method you generate cache for the document using the “DocumentCache” class before the moment, when end-user opens the document for displaying. And when the document is opening, GroupDocs.Viewer uses the previously generated cache.

As for canceling document load - you should abort “ViewDocumentHandler” request. You can do that with jQuery (which is included in to the GroupDocs.Viewer library). Please check this for how to abort ajax requests.

AOT Caching is not an option since files are generated dynamically.

The document is loaded via javascript call

var viewer = $('#pdfHolder');

viewer.groupdocsViewer("loadDocument", filename);

What specific call should I make using jQuery to abort "ViewDocumentHandler".

Thank you

Are there major differences between 2.4 and 2.6/2.7? When we used the 2.4 DLL, we are able to load a large document (218 MB, 2000 Pages), but is unable with 2.6 and 2.7.

From the fiddler, we can see the requests being sent, 200 status code returned, but the viewer is not showing anything. "Loading your content" message shows briefly, then it is a blank page.

On the server in the temp\cache directory, we do see somefiles (images are converted correctly)

(But in 2.4, the pages are showing one by one as we scroll, rather than the blank page)

We are only use IE browsers 8 - 11 with IE8 compatibility Mode. we tested in IE9 and 10, both have the same problem.

Thank you,

Update:

after waiting for a long time (some (not all) cache files are already in place under temp\Cache\ea0e8f44-fe01-43fa-bbc2-44f512c79d8a.pdf\2015-01-08T16_18_09\100@x.Pdf), the pages showed up for 2.6, but never with 2.7.

Also the print is not working either. Print Progress bar will display, but stuck at 0%.

Below is our settings of the viewer.

<% =Viewer.ClientCode()

.TargetElementSelector("#pdfHolder")

.ShowThumbnails(false)

.ShowFolderBrowser(false)

.ShowViewerStyleControl(false)

.ShowSearch(false)

.BackgroundColor("#2E4d7B")

.EnableRightClickMenu(false)

.DownloadPdfFileIfPossible(true)

.ShowDownload(AllowSave == 1)

.ShowPrint(AllowPrint == 1)

.PreloadPagesCount(1)

.SupportPageRotation(true)

.ShowOnePageInRow(true)

.ViewerStyle(ViewerMode.ScrollView)

%>

We are running IIS 7.5, framework 4.0 integrated.

Please let me know if you need more information from us to trouble shoot this problem. Unfortunately I can't provide the file since it is confidential.

Thank you,

Hello,

Thank you for describing the situation and providing a source code of the GroupDocs.Viewer widget.

You’ve said that you cannot send us a file which you are using in the GroupDocs.Viewer. But maybe you can send us the redacted/modified version of the document, where all confidential data is removed? Or sample file, which will have the same (approx.) size, page count, the same correlation between textual and image content, same layout and so on? The main requirement - there should be ability to reproduce all described issues with the file. Because it is hard to investigate the issue without having the target material. We have tried to reproduce your issues with big PDF files (800+ pages) using GroupDocs.Viewer version 2.7, but with no luck.

Also please say how you specify the document in the GroupDocs.Viewer widget. Are you using the “FilePath” or “Stream” method? If yes, using which parameters?

Thanks and waiting for your response.

We are using FilePath. We simply make the call using JS viewer.groupdocsViewer("loadDocument", filename);

After waiting for almost 20 minutes, the images showed up for version 2.7 as well.

Although we have PreloadPagesCount(1), it behaves like it is waiting for something process to complete before refreshing the page.

Majority of our PDF files are scanned from paper. Attached is a file I combined from various resources. The file is not very big, but it takes a while to show the first page. And when click on the second page, it is blank. (This has similar behavior).

CPU/Memory usage on the web server is quite high for w3wp.exe. After we close the browser, the process is still running on the server. Is there a command to kill it? Currently I goto task manager to kill.

Thank you,

Can I get an update on this? Are you able to replicate the issue with the file attached?

Thank you

Hello,

Sorry for the delay, we performed an investigation with the file.

We have used the document “34_InitialReview_2_001.pdf”, source code for the GroupDocs.Viewer widget from this your post, and viewer.groupdocsViewer(“loadDocument”, filename); for loading the document.

1. We were not able to reproduce the issue “when click on the second page, it is blank”. GroupDocs.Viewer shows all pages correctly.

2. But we observed an extremely long timespan when displaying the first page. GroupDocs.Viewer spends approximately 30 seconds from the moment when the document was requested and till the moment when the first page is rasterized (and appears in the “Processing” folder). It also spends additional 10 seconds to display this page image in the browser. We didn’t know yet the reason of such delay: is it a GroupDocs.Viewer bug, specific document or something else. Our developers are investigating this.

3. Unfortunately at this moment there is no possibility/command to stop the process of rendering the document. When you open the document, GroupDocs.Viewer begins to convert the document to the HTML-compatible form, and this process is unstoppable. So for this moment you can only restart the web-server, if you want to stop process.

We will notify you in this forum thread when the new info about the issue will arrive.

Sorry for the inconvenience.

Thank you for the update. I have used your demo project to load this file and ran into the same problem. What do you use for your web server? IIS 7.5, how much RAM, disk spaces. We have only 4GB RAM.

Hello,

1. GroupDocs.Viewer supports different version of the IIS (6+) and has no strict hardware requirements: if machine is able to run the .NET Framework, it also can run the GroupDocs.Viewer. When we performed an investigation of the “34_InitialReview_2_001.pdf” document, we used machine with Windows 7, IIS 7.5, 4 GiB RAM, 4 cores CPU - quite close to your configuration.

2. There is an everlasting story with big documents. Almost all customers, who use GroupDocs.Viewer with big documents, asked us about big rendering time, ways to increase performance and so on. Unfortunately, there is no magic bullet: big document cannot be opened and displayed in the browser instantly, like it happens when you open it using the Adobe Reader, for example. GroupDocs.Viewer needs to convert the document to the HTML-compatible form, create a set of several images of different sizes for every distinct document page, parse textual layer and so on. That’s why the document is opening so long.

3. However, there are several ways how to increase the performance.
3.1. First of all, using an ahead-of-time caching. The idea is to convert the document to the HTML-compatible form before the moment when it should be opened by the end-user.
3.2. In context of the “34_InitialReview_2_001.pdf” document the HTML-based mode can be much more quickly, because the document contains a lot of parsed text without very complicate layout and without lot of big images.
3.3. Use “MinimumImageWidth(value)” method. MinimumImageWidth: if set, the Viewer will load page images with the specified width from the server when starting. It will not load page images from the server again after zooming if the current page image size is smaller than the value specified and if the original (not scaled) page image size is smaller than the value specified. It means that in most cases the GroupDocs.Viewer will load page images only once and will not reload them after zooming in/out.
3.4. If this is possible for your business-logic, disable thumbnails (“ShowThumbnails(false)”).
3.5. If this is possible for your business-logic, disable ability to select text by using “SupportTextSelection(false)” method.

If you will have more questions please feel free to contact us.