Skip Headers
Siebel CRM Performance Tuning Guide
Siebel Innovation Pack 2015, Rev. A
E54321_01
  Go to Documentation Home
Home
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
View PDF  

5 Tuning Siebel Web Client for Performance

This chapter describes configuration options that affect the performance and throughput of the Siebel Web Client and provides guidelines for tuning the client to achieve and maintain optimal performance and scalability. It contains the following topics:

The following chapters in this guide also relate to Siebel Web Client performance:

For more information, see the following documents on the Siebel Bookshelf:

About Siebel Clients

A Siebel client is a computer that operates Siebel Business Applications, accessing data and services by way of one or more servers. The Siebel clients allow users to access information managed by Siebel applications. All Siebel deployments include one or more of the Siebel client types. You can deploy a mixture of clients.

The Siebel Business Applications client type covered in this book is the Siebel Web Client. This client runs in a standard third-party browser on the end user's client computer, and does not require any additional persistent software installed on the client.

Using HTTP, the browser connects to a Web server over a WAN, LAN, or VPN, or over the Internet. Through the Web server, the Siebel client connects to a Siebel Application Object Manager component on a Siebel Server, which executes Siebel application business logic and accesses data. Data is accessed from the Siebel database and can also be accessed from other data sources using virtual business components and a variety of integration methods.

Only the user interface layer of the Siebel Business Applications architecture resides on the client computer.

For more information about the Siebel Web Client and other client types, see the Siebel Installation Guide for the operating system you are using and Siebel System Administration Guide. For information about deploying Siebel applications using Siebel Open UI, see Deploying Siebel Open UI. For information about browser settings for Siebel applications deployed using high interactivity or standard interactivity, see Siebel System Administration Guide.

Performance Factors for Siebel Web Clients

Some performance considerations for Siebel applications involve processing or tuning activities on servers only, and do not affect Siebel client performance. However, many other such factors either directly or indirectly affect Siebel client performance. This chapter highlights some of the factors most directly related to the performance of the Siebel Web Client.

The performance of the Siebel client depends on many factors, some of which are summarized below. For additional information about these topics, see applicable documents on the Siebel Bookshelf.

About Supporting Multiple Siebel Modules

Depending on the specific Siebel Business Applications that you are using and how you deploy them, these applications and customer applications have different requirements and characteristics.

  • Employee applications, such as Siebel Call Center, use Siebel Open UI or high interactivity mode.

  • Customer applications, such as Siebel eService or Siebel eSales, use Siebel Open UI or standard interactivity mode.

All Siebel applications have many architectural elements in common. Multiple applications can use the same Siebel repository file (SRF). Each application uses its own Siebel Application Object Manager component. You might need to define, configure, and test multiple instances of each application to verify that your requirements are met in each usage scenario.

The performance of your Siebel applications will vary according to how you have configured the applications using Siebel Tools, custom browser scripts, or other methods. See "Following Configuration Guidelines".

Client performance will also vary according to which Siebel modules that you deploy. The performance of the Siebel client is highly dependent on feature functionality. Therefore, performance characteristics of Siebel modules will differ.

Some modules add special processing requirements. For example, Siebel CTI uses the Communications Session Manager (CommSessionMgr) component, and supports the communications toolbar and displaying screen pops in the client. Server and local resources support this functionality.

Supporting users who are dispersed in offices around the country or around the world introduces special deployment factors that can affect performance.

About Local Computer Resources

The resources available on each user's local computer must meet or exceed the recommendations outlined in the Certifications tab on My Oracle Support. Some performance enhancement measures depend directly on the available resources.

Guidelines for Siebel Web Client Tuning

Consider your hardware resources and requirements carefully prior to rolling out configuration changes, to make sure that business requirements have been met and the client performs as anticipated in the design phase.

Review guidelines presented elsewhere in this book, particularly in Chapter 12, "Tuning Customer Configurations for Performance," and in other relevant documents on the Siebel Bookshelf.

Ongoing testing and monitoring of your system performance is strongly recommended, because database characteristics change over time. To maintain an optimally performing system over time, you must plan for growth or other changes in your deployed application.

Activities that you perform to achieve performance and scalability goals might include the following:

  • Adjusting your system topology

  • Configuring the Siebel application in Siebel Tools or through other methods

  • Configuring Siebel Server components, particularly the Siebel Application Object Manager

  • Adjusting hardware resources available on local computers

  • Adjusting operating system settings on server or client computers

  • Adjusting Web server settings or network settings

  • Adjusting Web browser settings

  • Setting user preferences for Siebel applications

This topic contains the following information:

Providing Sufficient Web Server and Network Capacity

This topic is part of "Guidelines for Siebel Web Client Tuning".

Make sure that your Web server is appropriately configured to meet your performance requirements. See also "Specifying Static File Caching".

Make sure that your network capacity (bandwidth) meets your performance requirements, and that your environment supports full duplex Ethernet. In addition, it is highly recommended that you install all Siebel Servers on the same subnet. For more information, review the general requirements for Siebel Enterprise Server installation and configuration in the Siebel Installation Guide for the operating system you are using.

The following factors impact decisions regarding network bandwidth:

  • Application configuration. Large, complex views will require bigger templates, more controls, and more data to be sent from the Web server to the client. If bandwidth is an issue, then it is important to consider user scenarios to determine the optimal size and layout per view.

    For example, for views used frequently, reduce the number of fields displayed. For Siebel applications deployed using Siebel Open UI or high interactivity, the user can decide which columns are required in list applets. Rather than assuming a specific set, you can allow users to adjust it as necessary. Provide the minimal number of columns required in the base configuration. For more information, see Chapter 12, "Tuning Customer Configurations for Performance."

  • View layout caching. For Siebel Open UI or high interactivity mode, administrators can determine the number of views to be cached locally. If the hardware supports a greater number of views to be cached, then adjust the value accordingly. When a view is cached, subsequent visits will require a data update, but the Web templates do not need to be reloaded. This provides a substantial improvement in overall usability. For more information, see "Improving Performance Using View Layout Caching".

  • Login. The first login is generally the most expensive operation for the Siebel Open UI or high interactivity client. The client infrastructure caches the main components of the application on first login. Subsequent logins require far fewer resources. Cached objects remain on the client computer until the cache is cleared or a new version of the application configuration is available.

Testing Performance for Web Clients

This topic is part of "Guidelines for Siebel Web Client Tuning".

Oracle Advanced Customer Services offers general guidance based on information known about the characteristics of the configured Siebel application. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.

Customer testing is advised in any case, because assumptions are based on general data. Actual experience can vary due to use-case scenarios. Select a few of the most common scenarios: those that represent the highest percentage of activity. Collect the overall bandwidth used.

Make sure that you are testing with warm views (already visited and cached) if this is how the application will be used most of the time, assuming that users log in and use the application for four to eight hours at a time before logging off and starting a new session.

When you estimate bandwidth required for several users sharing a low-bandwidth connection, consider use-cases carefully and plan accordingly. Rather than planning for worst-case network-performance scenarios (such as all users simultaneous pressing the Enter key or visiting a new view), it is likely that very few users are actually using the network at the same time. For more information about performance monitoring, see Chapter 14, "Monitoring Siebel Application Performance with Siebel ARM."

Web client performance also depends on browser performance. For general information about this issue for Siebel Open UI, see Deploying Siebel Open UI.

Providing Sufficient Client Hardware Resources

This topic is part of "Guidelines for Siebel Web Client Tuning".

For best client performance for employee applications, provide sufficient or generous hardware resources to your end users. Requirements can vary according to your deployment.

The more memory that is available on your client computers, the greater the number of views that can be cached. For more information, see:

The speed of the processors (CPU) on your client computers will affect how quickly the Siebel application user interface is rendered.

For best performance for Siebel applications that are deployed using Siebel Open UI, it is generally recommended to use recent versions of browsers that support all applicable standards in your testing and in your user deployments. More recent versions often include fixes and performance enhancements.For best performance for employee applications that are deployed using high interactivity, it is generally recommended to include the latest supported version of Microsoft Internet Explorer in your testing and in your user deployments. More recent versions often include fixes and performance enhancements.

For best performance for the standard interactivity client, which is used by some customer applications, you must determine the minimum capabilities of customer environments, such as the browsers to support, processor speed, or expected Internet connection speed. Customer applications must support a wide range of customer environments. Accordingly, you generally minimize the complexity of such applications.

For Siebel client hardware and other platform requirements and recommendations, see the Certifications tab on My Oracle Support. For information about deploying Siebel applications using Siebel Open UI, see Deploying Siebel Open UIUI. For information about browser settings for Siebel applications deployed using high interactivity or standard interactivity, see Siebel System Administration Guide.

Tuning System Components

This topic is part of "Guidelines for Siebel Web Client Tuning".

Overall end user performance is affected by the processing on the client as well as by everything from the Web server to the Siebel database and back. Explore all applicable areas for opportunities to improve overall performance.

Most performance tuning involving Siebel Server components focuses on the Siebel Application Object Manager. For more information, see Chapter 3, "Tuning the Siebel Application Object Manager for Performance."

You can use Siebel ARM to monitor transactions through the Siebel infrastructure. Note areas which require substantial time and resources, and investigate them further for tuning opportunities.

For example, a custom configuration might have resulted in an unintentionally complex SQL statement for which the database instance has not been optimized. Small configuration adjustments in Siebel Tools, or database tuning, can improve both client performance and application scalability on Siebel Servers. For more information about Siebel ARM, see Chapter 14, "Monitoring Siebel Application Performance with Siebel ARM."

Following Configuration Guidelines

This topic is part of "Guidelines for Siebel Web Client Tuning".

For best performance by the Siebel client, carefully assess all customer configuration initiatives. All configuration changes must be justifiable in terms of the cost of configuration itself, and in terms of possible impact on performance.

Some application administration tasks might also affect application performance, and must also be carefully assessed.

Follow guidelines presented in Chapter 12, "Tuning Customer Configurations for Performance," or in other books on the Siebel Bookshelf.

Managing the Browser Cache

This topic is part of "Guidelines for Siebel Web Client Tuning".

Some types of Siebel application elements are stored in the browser cache, to improve performance when users log in or access Siebel views.


Note:

When measuring performance, take into account view layout caching or other types of caching. For example, performance is better when a Siebel view layout is retrieved from a cache than it is when the view layout is not cached and must be retrieved from the system. For more information, see "Improving Performance Using View Layout Caching".

Cache usage varies according to what browser is being used, what applications are running, and application settings. For browsers that are able to cache view layouts and other objects, using caching is recommended, to provide optimal performance.

Siebel Open UI and high interactivity applications use the browser cache more than standard interactivity applications do. It is generally recommended that users do not clear their browser cache, including when the browser is closed. Browser cache management details vary between browsers.

For example, high interactivity applications use the browser cache more than standard interactivity applications.

For example, for Microsoft Internet Explorer, you might use the following browser settings:

  • Choose Tools, then Internet Options. Click the Advanced tab. In the Security options, uncheck the setting Empty Temporary Internet Files Folder when browser is closed.


    Note:

    If you do not use this setting, then persistent view layout caching and preloading, described in "Improving Performance Using View Layout Caching", will not work.

  • Choose Tools, then Internet Options. Click the Advanced tab. In the Security options, uncheck the setting Do not save encrypted pages to disk.


    Note:

    If you do not use this setting, then persistent view layout caching and preloading, described in "Improving Performance Using View Layout Caching", will not work for encrypted views (that is, views encrypted using TLS).

  • Choose Tools, then Internet Options. In the General tab, click Settings. For the option Check for newer versions of stored pages, use the setting Automatically.

  • Browser caching is also subject to the size of the temporary Internet files folder. This setting is located in Tools, then Internet Options. In the General tab, click Settings, then specify the amount of disk space to use for this folder.


    Note:

    Setting the size of the temporary Internet files folder to 0 disables persistent view layout caching and preloading, which are described in "Improving Performance Using View Layout Caching".

Caching in the browser is also subject to Web server settings controlling static file caching. For more information, see "Specifying Static File Caching".

For Siebel client hardware and other platform requirements and recommendations, see the Certifications tab on My Oracle Support. For information about deploying Siebel applications using Siebel Open UI, see Deploying Siebel Open UI. For information about browser settings for Siebel applications deployed using high interactivity or standard interactivity, see Siebel System Administration Guide.

Specifying Static File Caching

This topic is part of "Guidelines for Siebel Web Client Tuning".

Browser caching behavior is also subject to Web server settings for static file caching. Appropriate settings allow files that are rarely updated, such as image files, JavaScript files, or style sheet files, to be cached on the browser. Caching static files reduces network utilization and enhances Siebel Web Client response time.

Caching for Siebel Web template files is described in the persistent view caching content in "Improving Performance Using View Layout Caching".

Because some static files can in fact be updated periodically, there is some risk that outdated versions of static files might be served from the cache. Therefore, some appropriate content expiration time must be specified. In general, setting an expiration time of 7 days might be appropriate.

If static files are rarely updated, then you can specify a larger number, for less frequent expiration. If static files are updated more often, then you can specify a smaller number, for more frequent expiration.

Instructions follow for specifying static file caching on Microsoft Internet Information Services (IIS), Apache Web Servers, and Sun Java System Web Server. You must restart your Web server for the settings to take effect. For more information, see your third-party Web server vendor documentation.

For more information about supported Web servers and versions, see the Certifications tab on My Oracle Support.For more information about tuning Web servers, see Chapter 13, "Tuning Operating Systems for Performance."

Static File Caching for Microsoft IIS

For Microsoft IIS, use the following procedure to specify static file caching and content expiration.

To specify static file caching on Microsoft IIS 

  1. On the Web server computer, choose Start, then Settings, then Control Panel, and then Administrative Tools.

  2. Run Internet Service Manager.

  3. In Internet Service Manager, right-click Default Web Site.

  4. In Default Web Site Properties, click the HTTP Headers tab.

  5. Check the Enable Content Expiration check box.

  6. Select Expire After, and specify the value of 7 (to expire static files after 7 days), or another value appropriate for your deployment.

Static File Caching for an Apache Web Server

For supported Apache Web Servers (Oracle HTTP Server, IBM HTTP Server, and HP Apache Web Server), use the following procedure to specify static file caching and content expiration.

To specify static file caching on an Apache Web Server 

  1. On the Web server computer, open the file httpd.conf for editing. This file is located in the Web server installation directory.

  2. Verify that the following line is included and not commented out:

    LoadModule expires_module modules/mod_expires.so
    
  3. Add the following lines, if not already present, to the file (below the line shown in Step 2). Or, instead of 7 days, specify another value appropriate for your deployment.

    ################################################################
    ExpiresActive On
    <IfModule mod_expires.c>
    ExpiresByType image/gif                   "access plus 7 days"
    ExpiresByType image/jpeg                  "access plus 7 days"
    ExpiresByType application/x-javascript    "access plus 7 days"
    ExpiresByType text/css                    "access plus 7 days"
    </IfModule>
    ################################################################
    
  4. Save the file.

Static File Caching for Oracle iPlanet Web Server

For Oracle iPlanet Web Server, use the following procedure to specify static file caching and content expiration.

To specify static file caching on Oracle iPlanet Web Server 

  1. From a browser, connect to the Web server administration page (for example, http://web_server_name/8080).

  2. Select the server, and click Manage.

  3. Click the link for Class Manager, in the upper right area.

  4. Among the horizontal tabs at the top, click Content Mgmt.

  5. Click the link for Cache Control Directives, in the left tab area.

  6. Under Cache Control Response Directives, select Maximum Age (sec), and input 604800 (seconds) for a valid cache of 7 days.

  7. Click Apply to apply the change.

Improving Performance Using View Layout Caching

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. It speeds up the rendering of views in a Siebel application session by caching the following on the browser:

  • Static HTML (from the templates) used for interpreting the view.

  • Dynamic HTML generated on the client for rendering controls.

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".

Two kinds of view layout caching are used for the Siebel Web Client. These types of caching work together and must be configured as a system.

For Siebel client hardware and other platform requirements and recommendations, see the Certifications tab on My Oracle Support. For information about deploying Siebel applications using Siebel Open UI, see Deploying Siebel Open UI.

View Layout Caching in Memory

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 about setting the view cache size, see "Setting the View Cache Size".

View layout caching uses the following logic:

  • If a user navigates to a view whose layout is already available in the browser memory cache, the HTML frame containing that view will be made visible and the currently visible frame will be hidden.

  • If a user navigates to a view whose layout is not in the browser memory cache, one of the available HTML frames will be used to load the layout of the view into memory. The view layout will be loaded from the persistent cache, if possible. The view layout in memory will be cached subject to the View Cache Size setting.

  • If the view layout is not currently stored in the persistent cache, then it is loaded from the server. It will also be stored in the persistent cache. The view layout in memory will be cached subject to the View Cache Size setting.

For more information, see "Persistent View Layout Caching".


Note:

With Siebel Open UI or high interactivity, the retrieval of the Siebel application user interface from the server is separate from 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".

Setting the View Cache Size

For browser memory caching, the size of the view layout cache is controlled by the View Cache Size user preference setting for each user, as described in this topic.


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".

To set the size of the view layout cache 

  1. From the application-level menu, choose View, then User Preferences.

  2. From the Show drop-down list, choose Behavior.

  3. In the View Cache Size field, select a value from the drop-down list, or type in a value.

The default value for View Cache Size is 10. This value specifies that ten HTML frames are cached in memory to represent Siebel view layouts. One of these frames is displayed at any one time.

  • Using a figure that is too low might not provide enough caching if your users access many views and client computers have sufficient memory.

  • Using a figure that is too high might impair performance by using more memory than is available on the computer.

Persistent 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.)

Persistent view layout caching helps improve performance by reducing the number of pages that have to be generated from the server from session to session.

The parameter WebTemplateVersion determines whether the Siebel Web Engine will use a view layout stored in the browser's cache or build a new view layout.

  • For Siebel Web Clients, set this parameter for the Siebel Application Object Manager component using Server Manager.

  • For Siebel Mobile Web Clients, this parameter is located in the [InfraUIFramework] section of the application configuration file, such as uagent.cfg for Siebel Call Center.

When you modify Web templates for Siebel views, set the WebTemplateVersion parameter to the value to 1. Subsequently, each time that 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.

When a view is requested, the Siebel Web Engine includes in the URL a checksum value that encapsulates the value of the WebTemplateVersion parameter.

  • If the parameter value and the value encapsulated in the URL match, then it is assumed that the view layout for this view has not been updated. If it is available, then the view layout stored in the persistent cache can be used.

  • If no match is found, then a new view layout is loaded from the server. The Web template on the server is presumably more current than the view layout stored in the browser's persistent cache.

Preloading Cached Views into Memory

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.

For better performance at login time, it can be helpful to further limit the number of view layouts that are preloaded into memory during startup. To do this, use the parameter ViewPreloadSize.

  • For Siebel Web Clients, set this parameter for the Siebel Application Object Manager component using Server Manager.

  • For Siebel Mobile Web Clients, this parameter is located in the [InfraUIFramework] section of the application configuration file, such as uagent.cfg for Siebel Call Center.


    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 might set this parameter to 0.

Disabling View Layout Caching

You can disable browser memory caching of view layouts for your application users by changing the parameter EnableViewCache to FALSE.

  • For Siebel Web Clients, set this parameter for the Siebel Application Object Manager component using Server Manager.

  • For Siebel Mobile Web Clients, this parameter is located in the [InfraUIFramework] section of the application configuration file, such as uagent.cfg for Siebel Call Center.


    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".

Setting EnableViewCache to FALSE disables browser memory view layout caching only. It does not disable persistent view layout caching.

Determining How the Current View Layout Was Loaded

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 Cached. The view layout was not cached (and cannot be cached).

  • Memory. The view layout was retrieved from the browser memory cache.

  • Server. The view layout was retrieved from the Siebel Server and the Web server. If the view is cacheable, and you visit another view and then return to this one, then the Cache Mode value changes to Memory.

  • Disk. The view layout was retrieved from the browser disk cache (persistent caching). If the view is cacheable, and you visit another view and then return to this one, then the Cache Mode value changes to Memory.

    The longer that you go without clearing the cache, the more likely that a rarely visited view will be retrieved from the persistent cache on the browser, rather than from the server.

Determining Whether Views Are Available for Layout Caching

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).

For detailed information about settings for the High Interactivity Enabled property for a class, see Siebel Object Types Reference.

View layout caching is also disabled for a view in the following cases:

  • If personalization rules are defined for any of the applets

  • If any of the applets are dynamic toggle applets

  • If any of the applets are hierarchical list applets or explorer (tree) applets

  • If HTML frames are used within the view template (for example, for explorer views)

Configuring the Data Block Size of HTTP Requests for the Siebel Developer Web Client

This topic is part of "Guidelines for Siebel Web Client Tuning".For the Siebel Developer Web Client, Siebel Business Applications use HTTP requests and responses to exchange information between the browser and the internal Web server that is part of the siebel.exe executable program. You can change the maximum length of the HTTP request data that is passed. By default, the maximum limit for the HTTP request is 524288 bytes (512 KB), which is typically sufficient. However, you can change this limit by configuring the DataBlockSize parameter in the [Siebel] section of the application configuration file, such as uagent.cfg for Siebel Call Center. If you change the value of this parameter, and restart the Siebel Developer Web Client, then the siebel.exe memory usage will reflect whatever value you set.

Managing Performance Related to Message Broadcasting

This topic is part of "Guidelines for Siebel Web Client Tuning".

Employee applications such as Siebel Call Center include the message broadcasting feature. The display of messages in the Siebel client requires network resources and local resources on the client computer to continually update the displayed text.

  • If your deployment does not require it, then turn off the message broadcasting feature to save processing resources.

  • If some of your users require message broadcasting, then you can specify that users will be able to turn it off by choosing Tools, then User Preferences, and then Message Broadcasting.

For more information about message broadcasting, see Siebel Applications Administration Guide.

Configuring the Busy Cursor for Standard Interactivity Applications

This topic is part of "Guidelines for Siebel Web Client Tuning".

When the parameter EnableSIBusyCursor is set to TRUE (default), the Siebel application cannot accept new requests until it has finished serving the current request. An example of a new request is a user's attempt to drill down on a record.

The default setting of this parameter helps prevent the occurrence of JavaScript errors as the user cannot click on another link while a page is loading. Setting EnableSIBusyCursor to FALSE can improve network bandwidth usage for Siebel applications that use standard interactivity mode. It disables the appearance of the hourglass icon and allows the user to click on other links before the current request has been served.

To set a value for the EnableSIBusyCursor parameter, set this parameter for the Siebel Application Object Manager component using Server Manager.