|Bookshelf Home | Contents | Index | PDF|
This topic is part of Guidelines for Siebel Web Client Tuning.
View layout caching in the browser (also referred to as layout caching or view caching) improves the performance of accessing views in a high interactivity application. It speeds up the rendering of views in a Siebel application session by caching the following on the browser:
Appropriate caching settings can optimize client performance and network utilization for Siebel client sessions. Caching behavior is subject to considerations described under Managing the Browser Cache.
NOTE: Whether views can be cached depends on the underlying requirements described in Determining If Views Are Available for Layout Caching.
View layout caching in memory creates multiple HTML frames on a browser to store the layout for a view. The number of these frames represents the view cache size. When a view is displayed, the HTML frame containing the layout for that view will be sized to occupy all (100%) of the available browser space, while the other frames will be hidden (that is, sized to occupy 0% of the space). For information on setting the view cache size, see Setting the View Cache Size.
For more information, see Persistent View Layout Caching.
NOTE: The high interactivity framework separates the retrieval of the Siebel application user interface from the server and the retrieval of database records. Database records to be displayed in views are always retrieved from the server.
The memory cache contains the layouts of views that the user has visited and that are available for view caching. When the view cache is full and another view is visited, the first view visited is removed from the cache. The memory cache contents are thus managed on an LRU or least recently used basis.
The HTML frames are loaded into memory when a user navigates to the view. To cache a startup view (one that is cacheable), the user must visit the view twice (that is, visit the view a second time, after visiting another view).
The view caching framework is designed so that if the frames containing cached views are deleted (for example, by performing a browser refresh, which removes any previously cached views), the framework begins reloading the layout cache, starting with the next cacheable view the user visits.
At startup, view layouts for recently visited views can be preloaded into the memory cache from the persistent browser cache on disk. This behavior is specified using the parameter ViewPreloadSize. For more information, see Persistent View Layout Caching and Preloading Cached Views into Memory.
NOTE: Setting View Cache Size to 1 turns off view caching. This has the same effect as setting the EnableViewCache parameter to FALSE, as described in Disabling View Layout Caching.
Persistent layout caching stores the layout of certain views in a local client's browser cache on disk. The stored layout is then reused for subsequent visits to this view, in the same session or in a subsequent session. (For subsequent visits in the same session, the view layout is accessed from the browser memory cache, if available.)
When you modify Web templates for Siebel views, set the WebTemplateVersion parameter to the value to 1. Subsequently, each time you change any of the Web templates, increment the value of the parameter by 1. Doing so forces loading view layouts from the Web templates on the server.
For recently visited views, view layouts that are cached in the persistent cache on the browser can be preloaded into browser memory when the user logs in. The number of views that can be preloaded depends on the content of the persistent cache and is limited by the setting of the View Cache Size setting for each user.
NOTE: ViewPreloadSize only affects a user session when it is set to a positive integer value lower than the View Cache Size value. If the parameter is not set, then the default behavior is to preload the number of view layouts corresponding to the View Cache Size value, minus one. (One of the frames specified using View Cache Size is reserved for the application startup view, where applicable.)
If ViewPreloadSize is set to 0, then no view layouts are preloaded into memory. In scenarios where users frequently log into the Siebel application, such as to access a single view, then log out again, login performance might be more important than precaching multiple views. In this case, you can choose to set this parameter to 0.
NOTE: In general, setting EnableViewCache to TRUE is recommended. If some users do not need view layout caching, then they can set View Cache Size to 1, as described in Setting the View Cache Size.
If you are running an application and want to determine how the current view was retrieved, then go to the view, press SHIFT, and choose Help, then About View. The Cache Mode identified for the current view indicates how the application retrieved the view layout. Possible values include:
Not all Siebel views are available for layout caching. Views that contain applets that have dynamic layouts or controls that are data-dependent cannot be cached. Only applets that support high interactivity are available for view layout caching.
Layout caching is a feature of the C++ class that implements an applet. The ability to be cached is determined by a property of each applet's class object definition. Using Siebel Tools, check the value of the High Interactivity Enabled property of a class object definition to determine whether applets for this class support layout caching. For a view to be available for caching, the class objects for all of the applets in the view must have High Interactivity Enabled values of 2 or 4 (available for caching).
|Siebel Performance Tuning Guide||Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices.|