| Siebel CRM Performance Tuning Guide Siebel 2018 E24801-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Performance Tuning Guide Siebel 2018 E24801-01 |
|
Previous |
Next |
View PDF |
Using your hardware resources optimally, and configuring your system appropriately, can help you to achieve your performance goals. Consider your resources and requirements carefully, and test and monitor system performance on a continual basis.
Review information presented in Siebel CTI Administration Guide, Siebel System Administration Guide, relevant third-party documentation, and other sources.
Activities that you can perform to achieve performance and scalability goals include, but are not limited to, the following:
Adjusting your system topology. For more information, see "Topology Considerations for Session Communications".
Configuring the Siebel Application Object Manager component.
Configuring CommSessionMgr and related components.
Modifying communications configurations, communications driver settings, and so on. Many of the activities described in the topics that follow are of this nature.
To maintain an optimally performing system over time, you must plan for changes in the volume of incoming communications, number of users, and so on. Verify that your CTI middleware can support an anticipated increase in the volume of incoming communications and in the number of users. Then additional hardware might be required to run more Siebel Application Object Manager components and CommSessionMgr components to support the increase in volume of communications and in number of users.
This topic contains the following information:
This topic is part of "Guidelines for Session Communications Tuning".
In general, CommSessionMgr and CommConfigMgr components use a small percentage of the resources of the Siebel Server on which they run, while Siebel Application Object Manager performance has the greatest effect on overall system performance, even when the communications components are present. (However, the resources used by CommSessionMgr depends on call center activity and on the third-party communications driver in use.)
Siebel Application Object Manager memory requirements for agent sessions depend on many factors. Siebel Application Object Manager memory usage for an agent using session communications is greater than for other users (those who are not defined as agents in a communications configuration).
Siebel Application Object Manager tuning also depends on your communications configuration caching methods. See also "Conserving Siebel Application Object Manager Server Resources Through Caching". For more information about Siebel Application Object Manager tuning, see Chapter 3, "Tuning the Siebel Application Object Manager for Performance."
This topic is part of "Guidelines for Session Communications Tuning".
For the CommSessionMgr component, the MaxTasks parameter determines the maximum number of communications events that can be processed at one time.
Generally, the default values are appropriate for the MaxTasks, MinMTServers, and MaxMTServers parameters, particularly if CommSessionMgr runs on each Siebel Application Object Manager computer.
If you use a dedicated Siebel Server computer to run the CommSessionMgr component, then it might be appropriate to set these parameters to higher values to optimize usage of server resources such as CPU and memory. See also "Topology Considerations for Session Communications".
This topic is part of "Guidelines for Session Communications Tuning".
You can use two caching mechanisms to make communications configuration data load faster for each agent session and to reduce demand on server resources on the Siebel Application Object Manager.
These caching mechanisms can be used together or separately. For more information, see Siebel CTI Administration Guide.
CommConfigCache parameter (Siebel Application Object Manager). Setting the CommConfigCache parameter on the Siebel Application Object Manager to TRUE caches communications configuration data when the first agent logs in. Configuration data is cached until the Siebel Application Object Manager is restarted. For agents associated with the same communications configuration, each agent session uses the same cached data. See also "Tuning the Siebel Application Object Manager Component".
Performance is improved for subsequent agent logins, because the configuration data is loaded from the cache rather than from the database.
Siebel Application Object Manager scalability is also improved because configuration data is shared in Siebel Application Object Manager memory across agent sessions, therefore conserving server resources even as the number of agent sessions increases.
CommConfigMgr server component and CommConfigManager parameter (Siebel Application Object Manager). The CommConfigMgr server component caches communications configuration data when the first agent logs in. Setting the CommConfigManager parameter on the Siebel Application Object Manager to TRUE enables this server component.
Performance is improved for subsequent agent logins, because the configuration data is loaded from the cache rather than from the database.
Using the CommConfigMgr component to cache data speeds up the login process and reduces memory usage per agent session because the component uses configuration data that was already cached on the Siebel Application Object Manager component.
Although it is not required to use the CommConfigMgr component in conjunction with the CommConfigCache parameter for Siebel Application Object Manager, if you use them together, then communications configuration data gets cached at the enterprise level rather than only for the Siebel Application Object Manager. Overall performance can be enhanced compared to using each of these mechanisms separately.
This topic is part of "Guidelines for Session Communications Tuning".
When you deploy session communications, you create communications configurations, define employees as agents, and associate each agent with one or more configurations. How you do these things affects performance and scalability.
In a deployment supporting a large number of agents across multiple physical sites, you must determine criteria for grouping your agents within configurations.
For example, some dialing filters that you define, using the parameter DialingFilter.RuleN, might be appropriate for agents at a specific place, such as within the same country or area code. Other dialing filters might be suitable for a different set of agents.
In addition, some switch, teleset, or CTI middleware settings are reflected in your communications configuration, and can differ between physical locations.
It might be helpful to define a communications configuration to apply to users at a single location only. In addition to simplifying the process of defining communications configurations, telesets, or other elements, this approach can help you reduce demand on server resources such as Siebel Application Object Manager memory or CPU.
If call transfers or similar functions are to be supported between contact centers, then additional configuration issues apply.
For more information about defining communications configurations and agents, see Siebel CTI Administration Guide.
This topic is part of "Guidelines for Session Communications Tuning".
Logging data can be analyzed as part of performance monitoring or tuning, as described in Chapter 14, "Monitoring Siebel Application Performance with Siebel ARM."
Higher levels of logging provide more data to help you resolve system errors or performance issues; this is appropriate for system testing. For production systems, however, logging levels must be reduced to improve performance.
Log-related parameters applicable to session communications are summarized in this topic. The Siebel Application Object Manager component logs activity related to the user's client session, including usage of the communications toolbar, screen pops, and so on. The CommSessionMgr logs activity related to this component, such as commands and events for the communications driver.
The logging for Siebel Application Object Manager and CommSessionMgr are written to separate files for each user. Typically (though not necessarily), these logging mechanisms both write into the same set of files. This makes it easier to monitor or troubleshoot issues related to session communications for a particular user session. For more information about these logging parameters, see Siebel CTI Administration Guide.
Siebel Application Object Manager parameters that log session communications activity include:
CommLogFile. Specifies the name of the log file (default value is SComm.log). A separate log file is created for each agent session, in the form SComm_username.log.
CommLogDebug. Specifies whether log files must contain extra detail. Setting this parameter to FALSE provides better performance.
CommMaxLogKB. Specifies the maximum size of log files.
CommReleaseLogHandle. Specifies that the log file handle must be released periodically. The default setting of TRUE provides better performance.
CommSessionMgr parameters that log session communications activity include:
LogFile. Specifies the name of the log file (default value is SComm.log). A separate log file is created for each agent session, in the form SComm_username.log.
LogDebug. Specifies whether log files must contain extra detail. Setting this parameter to FALSE provides better performance.
MaxLogKB. Specifies the maximum size of log files.
ReleaseLogHandle. Specifies that the log file handle must be released periodically. The default setting of TRUE provides better performance.
This topic is part of "Guidelines for Session Communications Tuning".
When agents log in to the Siebel application after experiencing browser failure or a dropped connection, session communications might sometimes remain unavailable.
Session communications availability can be considered a performance issue. In addition to affecting agent productivity, loss of availability of session communications wastes server resources that could support other functions.
You can improve session communications availability by using the following mechanisms:
Push Keep Alive driver. Using the Push Keep Alive communications driver pushes empty messages (heartbeat messages) to agents at regular intervals. In this manner, it helps keep the communications push channel alive. This feature can help in environments where enforced timeouts sometimes cause communications session connections to be dropped.
For example, many customers deploy some kind of network appliance to load-balance Web servers. By default, such network appliances can time out connections to browsers, causing communication interruptions for agents. The Push Keep Alive driver generates periodic traffic so connections do not time out due to inactivity.
To use the Push Keep Alive driver, you create a driver profile, and specify a heartbeat interval (such as 180 seconds) using the PushKeepAliveTimer driver parameter. Then you add this profile to your communications configurations.
ChannelCleanupTimer parameter (communications configuration). The ChannelCleanupTimer parameter for communications configurations reduces reconnection delays related to session timeouts. This parameter allows the system to identify when a connection is no longer functioning; for example, due to dropped connections or browser failure. If you are using the Push Keep Alive driver, then it is recommended to also use the ChannelCleanupTimer parameter.
CommMaxMsgQ and CommReqTimeout parameters (Siebel Application Object Manager). In addition to setting general application timeouts, setting the Siebel Application Object Manager parameters CommMaxMsgQ and CommReqTimeout can also help you manage agent connections effectively.
Backup Communications Session Manager (CommSessionMgr) component. A backup CommSessionMgr component can be specified using communications configuration parameters. The backup CommSessionMgr component runs on another Siebel Server computer and can be accessed without agent interruption in case the primary CommSessionMgr component fails and does not restart.
For more information about using these features, see Siebel CTI Administration Guide.
This topic is part of "Guidelines for Session Communications Tuning".
Screen pop response time as experienced by contact center agents is an important indicator of acceptable performance. A screen pop is the display of a view and, optionally, specific records, in response to a communications event. Such events are typically received from CTI middleware; for example, an incoming call is ringing, or the agent has answered the call.
Screen pop behavior is determined by call-handling logic that applies to a particular call based on data attached to the call. Behavior for individual agents is also affected by user settings in the Communications section of the User Preferences screen.
Screen pop performance is affected by the relative complexity of your communications configuration elements, such as event handlers and event responses, and by scripts or business services that might be invoked. Query specifications, database performance, and network capacity and latency also affect screen pop performance. For related information, see "Improving Performance for Communications Configurations". For more information about Siebel Web Client response time, see Chapter 5, "Tuning Siebel Web Client for Performance."
This topic is part of "Guidelines for Session Communications Tuning".
By default, for each communications work item, an activity record is created in the S_EVT_ACT table and related tables.
As you plan your deployment, you must consider how or whether such records are created, review the indexing and layout of applicable database tables, and review the performance impact of generating activity records.
