Performance Tuning for Server side rendering - Daeja ViewONE Virtual

Documents are rendered on the server and image tiles are generated for each page. The client-embedded viewer fetches these images from the server across the network that could produce several network requests of many small data packages. The page displaying speed is bounded by the performance of the network between the client and server, and the available resources on the server.
 

Tuning options - all supported formats:

The current default behavior of the viewer is to preFetch 7 pages +/- the current page* and to break down the page into tile sizes measuring 256x256 pixels.

This means that typically anything 6 - 20 tiles can be required to deliver a single page. The number of tiles depends on the image size and resolution itself plus other factors such the current zoom level or use of thumbnails. The number of tiles then needs to be multiplied by the number of pages being prefetched.

With the default prefetch of 7 and many tiles per page (say, 20 for a more complex image), this can mean that around 150-200 separate network requests have to be fulfilled just to view the first page of a document.

Experience in the field has demonstrated that for *some* networks, the level of network "chattiness" caused by each page being made up of a number of tiles  can be detrimental to the perceived performance of the viewer.  For such cases, it has been found that reducing the number of tile requests to around 1 per page (by increasing the specified tile sizes) has had a positive impact on the performance of the viewer. In order to reduce the number of tiles being delivered to approximately 1 per page (in most cases) the following tile size settings are suggested:

<param name="tileXSize" value="3000">
<param name="tileYSize" value="3000">

Adjustments to the "preFetchSize" parameter should be based on the actual workflow of the users. For a system where users are typically viewing smaller documents and more interested in the best "time-to-view" first page rather than viewing many pages of a large document using continuous scrolling, you may want to consider lowering this to a value of around 0,1 or 2 to reduce the amount of increased network activity with prefetching +/- 7 pages

<param name="preFetchSize" value="0">

For a system where users are typically viewing large multi page documents and want to scroll through them seamlessly, it is suggested that the preFetchSize is left at the default value of +/- 7 pages since that was determined through extensive load testing internally at IBM to be the optimal value for seamless scrolling without causing memory and resource issues in the client-side browser\server JVM heap

Please note that any value of preFetchSize > 7 is not valid and will not be used by the viewer - only a maximum value of +/- 7 pages is allowed for continuous scrolling, anything more is likely to cause significant issues with both the client-side browser resources and even more importantly resources used up on the server.