Free Support Forum -

SystemOutOfMemory with a massive use of viewer

Hi, we encountered some problems with some of our customers using the viewer version 2.16 and
We use HtmlBasedEngine property set to "true" and the property PreloadPagesCount set to "2".
We noticed that especially with files that contain a relatively large number of pages (greater than 10), the iis pool begins to consume a lot of RAM, as well as the private memory used.
This is because even if it is set to 2 the number of pre-loaded pages, the viewer continues to write the pages rendered in html on the cache folder, until that have not been rendered all the pages.
If you multiply this problem for a large number of users, the issue it raises is an exception of SystemOutOfMemory and consequently the recycle of the pool, and then the expiry of sessions.
Now we have turned off the viewer on the customers who experienced this problem, but we have to give a solution to these customers.
The thing that we do not understand is the use of the property PreloadPagesCount which in this case is ignored.
We are waiting for your feedback.

Thank you


Thank you for the question. By default, when you open a web-page with GroupDocs.Viewer widget, and the target document is invoked (for displaying), on the server-side GroupDocs.Viewer converts the document to the images and text. Only when this conversion process is finished, GroupDocs.Viewer begins to transmit data to the client-side and end-user can see content of the document in the browser. That’s why it takes so much time - GroupDocs.Viewer needs to convert all document, and they are really big. The conversion speed depends on the performance of the server - CPU, memory, storage.

When using PreloadPagesCount option, for example, “.PreloadPagesCount(1)”, GroupDocs.Viewer begins to transmit data to the client-side when only first page of the document is converted. After applying this method to the document (17 MiB), GroupDocs.Viewer shows its first page almost instantly. All other pages are shown on demand, when you try to open them.

There are some other methods to increase performance:
1. 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.
2. If this is possible for your business-logic, disable thumbnails (“ShowThumbnails(false)”).
3. If this is possible for your business-logic, disable ability to select text by using “SupportTextSelection(false)” method.
4. Use “ShowViewerStyleControl(false)” method - it will disable “double page flip” option and will increase performance.
5. Pre-generate document cache with DocumentCache class

Also I should notify you that the version of the GroupDocs.Viewer that you use is a very old version which is not supported any more. Please migrate to the latest version if possible. You should note that the latest version is a UI less and you will need to develop your own UI.

Best regards.

Hello, we tried with your suggestion.

It seems that something has improved.
But we don’t understand what do you mean with PreloadPagesCount. You mean that with this option, only the pages indicated will be loaded? Because we see that also with this option, it continues to render in html all the pages 'til the end of the document. If I have a document with 1600 pages, it will continue until p1600.html is created.
Thank you