Hi,
Same problems occur while loading mid size Excel file (attached). The latest version has a bug and memory leak (CPU is 100% and memory consumption rises 4 times). The process is being looped - prev versions worked fine. This is a crucial issue.
Hello Piotr,
We are sorry to hear that you have such issue. I have viewed your excel file with the latest Viewer and all work fine, as you can see on the screenshot the document is viewed and it takes about 11 seconds for the first time (when there is no cache for it) and it takes 6 seconds when the cache is created.
Since that could you please share with me next:
1. The Viewer widget code that you use
2. The exact version of the library
3. Which browser you use?
Thank you.
Hello Pavel,
Try with the latest dll v.2.19.
Your screenshot has been taken from 2.18 which was working fine as I remember.
Piotr
Hello Piotr,
Thank you for your details.
Sorry, but we still can not reproduce the same issue at our side , with the GroupDocs.Viewer for .NET 2.19.0 version we not see any jumps of CPU memory consumption . So please share with us these details:
1. The Viewer widget code that you use
2. The type of project
3. Which browser you use?
----------
Best regards,
Evgen Efimov
http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+
Hello,
Please examine attached codefile. We use classic asp.net and latest Chrome browser and use preload method.
Today once again we have made a comparison test 2.19 versus older 2.16. The older one showed first page in about 15-19 seconds while the latest one was processing the same .xls file for over 3 minutes! Server memory consumption rised in a seconds from 250MB to over 800MB.
Another issue I have found is that after upgrading dll from 2.16 to 2.19 all docs ended with error (the viewer couldn’t load file). Problem was resolved after clearing Chrome browser’s cache. How can we avoid such errors in the future upgrades? I suppose it was due to old scripts cached in browser but I’m not sure how we could mitigate this.
Piotr
Hello ,
Thank you for your code example.
We have reproduced the issue on our side . We will investigate the issue with our product team and when we will have any news you will be notified here.
As a temporary solution I can recommend you to use html mode for Viewer .UseHtmlBasedEngine(true) , if it is possible for your use-case.
We apologize for the inconvenience.
--------
Best regards,
Evgen Efimov
http://groupdocs.com
Your Document Collaboration APIs
Follow us on LinkedIn, Twitter, Facebook and Google+
Hi,
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 (for the image-based rendering) or to the HTML, images, fonts, and CSS (for the HTML-based rendering). 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.
Here is some methods to increase performance:
1. Try to use HTML-based rendering mode (“UseHtmlBasedEngine(true)” method) if it is suitable for you and there are no document distortions.
2. 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. If this is possible for your business-logic, disable thumbnails (“ShowThumbnails(false)”).
4. If this is possible for your business-logic, disable ability to select text by using “SupportTextSelection(false)” method.
5. Use “ShowViewerStyleControl(false)” method - it will disable “double page flip” option and will increase performance.
6. Generate document cache with “DocumentCache” class before the document will be opened in the Viewer.
Also we will release a next generation Viewer library soon so you can wait and try to use it.
Best regards.
Hi Pavel
Thank you for a quick guide.
I tried to use UseHtmlBasedEngine(True) with my code and error occured after scrolling to see next pages (screen attached). This issue hasn’t been spotted untill switching to html mode.
I’d like to ask you about second part of my ticket request (errors with browser cache after upgrade) because there was no answer for this.
Hi,
Sorry, but I can’t reproduce your issue, since that could you please share with me example of your project that I can check it and reproduce the issue.
As for the question about the browser cache - sorry but it’s impossible to manipulate with the browser cache from the Viewer, but you can check common way described here
Thank you.