| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
Previous |
Next |
View PDF |
This chapter describes some issues that affect the performance and throughput of selected functionality for Siebel Communications Server modules, and provides guidelines for tuning these modules to achieve and maintain optimal performance and scalability. Functionality described in this chapter includes session communications (typically, Siebel CTI) and Siebel Email Response. Other communications-related modules are not described.
This chapter contains the following topics:
For more information about Siebel Communications Server, see the following documents on the Siebel Bookshelf:
Siebel CTI Administration Guide
Siebel Email Administration Guide
Siebel System Administration Guide
Siebel Deployment Planning Guide
Siebel Communications Server provides an infrastructure to support several kinds of communications activities for Siebel application users. For session communications performance tuning information, see "Session Communications Infrastructure" and subsequent topics. For Siebel Email Response performance tuning information, see "Siebel Email Response Infrastructure" and subsequent topics.
Session communications. Supports interactive (session) communications for contact center agents who use the multichannel communications toolbar to:
Make or receive voice calls using computer telephony integration supported by CTI middleware or other third-party products.
Receive inbound email messages (for Siebel Email Response).
Inbound communications. Supports integrating with third-party email servers and processing inbound email (when using Siebel Email Response).
Outbound communications. Supports integrating with a variety of third-party communications systems, such as email servers or wireless messaging providers, to send outbound communications.
Supports agents sending email replies using Siebel Email Response.
Supports the Send Email and Send Fax commands for Siebel application users. (Send Page is also available, but uses the Page Manager server component.)
Supports users sending outbound communications content (email, fax, or page) using communication requests. Requests can be created and submitted either programmatically or manually through a user interface described in Siebel Email Administration Guide.
Many Siebel modules invoke business service methods through workflows to send outbound communications.
Session communications refers to using Communications Server components to enable contact center agents or other users to handle interactive communications work items. For example, Siebel CTI supports this capability, enabling agents to handle voice calls using the communications toolbar.
It is important to understand the infrastructure that supports session communications in order to prevent or address performance issues in this area.
Session communications performance is addressed in this topic and in:
Session communications are supported in the Siebel Server environment primarily by the following components:
Communications Session Manager (CommSessionMgr). This server component manages interactive communications work items such as voice calls.
Siebel Application Object Manager. This server component manages application sessions for end users who use the Siebel Web Client, including users who handle communications work items (agents). Interactive communication requests from agents typically go through Siebel Application Object Manager. For more information about Siebel Application Object Manager, see Chapter 3, "Tuning the Siebel Application Object Manager for Performance."
Server Request Broker (SRBroker). This server component handles communications between the Siebel Application Object Manager and certain other Siebel Server components, including CommSessionMgr.
For example, when a call center agent using Siebel CTI makes a call through the communications toolbar, the request goes from Siebel Application Object Manager to CommSessionMgr by way of SRBroker.
SRBroker is used whether CommSessionMgr runs on the same computer as the Siebel Application Object Manager, or on a different computer. For more information about such scenarios, see "Topology Considerations for Session Communications". For more information about SRBroker, see "Tuning Server Request Broker (SRBroker)".
You might also be using the following components in your Siebel Server environment and communications infrastructure:
Communications Configuration Manager (CommConfigMgr). Optionally used to cache communications configuration data.
Communications Inbound Receiver (CommInboundRcvr). For more information, see "Siebel Email Response Infrastructure".
Communications Inbound Processor (CommInboundProcessor). For more information, see "Siebel Email Response Infrastructure".
Communications Outbound Manager (CommOutboundMgr). Sends outbound email or other types of messages.
You might be using third-party product modules such as CTI middleware, driver, and configuration; routing products; predictive dialers; interactive voice response modules; email servers; fax servers; and so on. For more information about working with third-party CTI middleware products, see Siebel CTI Administration Guide. For more information about working with third-party email servers, see Siebel Email Administration Guide.
This topic describes factors that drive or affect performance for session communications deployments.
Depending on your deployment, your agents can be handling phone calls (Siebel CTI), email messages (Siebel Email Response), work items of other communications channels, or a combination of these.
Inbound calls processed per hour. The number of inbound calls (or other types of work items) processed per hour (or some other time period) by your communications infrastructure.
Outbound calls processed per hour. The number of outbound calls processed per hour (or some other time period) by your communications infrastructure. (For outbound predictive dialer calls, only the calls that are answered and processed by Communications Server are relevant here.)
Number of user communications actions per minute (load). The average number of communications-related user actions per minute, and the average think time between such user actions. Communications-related actions typically refers to actions performed using the communications toolbar.
Longer think times mean less load on the Siebel database and the Siebel Server. Think time is an important factor in overall system load. Estimation of think time must approximate actual user usage. For more information about think time and Siebel Application Object Manager tuning, see Chapter 3, "Tuning the Siebel Application Object Manager for Performance."
Number of concurrent communications users (agents). The number of concurrent users of session communications features (typically, contact center agents). This figure will be some percentage of the total number of concurrent users on the Siebel Application Object Manager.
You also need to understand how agents work with these features, the average number of inbound and outbound work items per agent, and how these factors relate to your organization's service goals. Some agents receive a large number of work items from ACD queues or initiate a large number of work items. Supervisors or other users can be defined as agents but might receive only escalated work items, for example. For more information about concurrent users and Siebel Application Object Manager tuning, see Chapter 3, "Tuning the Siebel Application Object Manager for Performance."
Volume of customer data. The total volume of customer data. Data volume affects how quickly data can be retrieved for various purposes, such as to perform lookups for screen pops, route work items, or populate the customer dashboard. In many cases, data volume directly affects response times seen by agents. The volume of data must be realistic and the database must be tuned to reflect real-world conditions.
These and many other factors (such as the average call time, average time between calls for an agent, and so on) will affect system performance as experienced by contact center agents. An agent will be concerned with general response time, screen pop response time, and other perceived measures of performance.
Review information presented in applicable third-party documentation for any requirements that affect your deployment. For example:
Some CTI middleware software might place limitations on the number of agents that can be served at a single contact center site.
Integration with ACD queues, predictive dialers, or other modules can affect your configurations, affect network traffic, or have other impacts.
The capacity of your telephony link (between the ACD switch and the CTI middleware) can affect performance.
Generally, Siebel Communications Server components for session communications, such as CommSessionMgr, must run on the same Siebel Server computers as those running Siebel Application Object Managers. In some cases, however, you must run CommSessionMgr on a different computer than the Siebel Application Object Managers. These options are described in detail in this topic.
CTI middleware generally runs on servers located at each contact center facility.
Generally, Siebel Communications Server components for session communications must be run on the same Siebel Server computers as those running Siebel Application Object Managers. Such a topology allows the Siebel Application Object Manager load-balancing mechanism to indirectly balance Communications Server load. CommSessionMgr loads are fairly light and do not, in themselves, present a reason to run this component on dedicated computers.
Set the Enable Communication parameter to TRUE for all Siebel Application Object Managers to which your agents will connect. If you are using Siebel Server load balancing, then all Siebel Application Object Managers to which requests are distributed must be configured the same way.
Sometimes you must run CommSessionMgr on a different computer than the Siebel Application Object Manager components.
CommSessionMgr must run on the same computer where the communications driver for your CTI middleware is running. If your driver requires a particular operating system platform, then you must install Siebel Server and run CommSessionMgr on a computer of this platform. Communications drivers are required to be able to run on one of the supported Siebel Server platforms, as described in the Certifications tab on My Oracle Support.
If your Siebel Application Object Manager components (such as Call Center Object Manager) run on computers using a different platform, then you set several parameters in the communications configuration, including CommSessionMgr and RequestServer, in order to designate the computer where CommSessionMgr is running. All communications session requests from a Siebel Application Object Manager supporting users for this communications configuration will be routed to the CommSessionMgr component on the dedicated computer. For related information, see "Tuning the CommSessionMgr Component". For more information about these parameters, see Siebel CTI Administration Guide.
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".
CommSessionMgr and CommConfigMgr components use a small percentage of the resources of the Siebel Server on which they run. Siebel Application Object Manager performance has the greatest effect on overall system performance, even when CommSessionMgr or CommConfigMgr components are present.
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 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 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 into 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 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.
|
Note: If you are using the Push Keep Alive driver, then you must also use theChannelCleanupTimer 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.
Siebel Email Response uses Communications Server components to enable contact center agents to read and respond to inbound email messages.
It is important to understand the infrastructure that supports Siebel Email Response communications in order to prevent or address performance issues in this area.
Siebel Email Response performance is addressed in this topic and in:
Siebel Email Response is supported in the Siebel Server environment primarily by the following components:
Communications Inbound Receiver (CommInboundRcvr). Receives and queues inbound work items, and queues them for processing by Communications Inbound Processor.
For nonreal-time work items, such as email messages for most deployments of Siebel Email Response, Communications Inbound Receiver queues work items it has received for further processing by Communications Inbound Processor.
For real-time work items, such as phone calls for Siebel CTI or email messages for some deployments of Siebel Email Response, Communications Inbound Receiver processes work items it has received. Communications Inbound Processor is not used.
Communications Inbound Processor (CommInboundProcessor). Processes inbound work items that were queued by Communications Inbound Receiver.
Communications Outbound Manager (CommOutboundMgr). Sends outbound email or other types of messages.
Siebel File System Manager (FSMSrvr). Writes to and reads from the Siebel File System. This component stores inbound messages prior to processing and stores attachments to inbound and outbound email messages.
In addition to Siebel Email Response, you might be using Siebel Assignment Manager and Siebel Workflow for routing email messages to agents.
Siebel Email Response works in conjunction with your third-party email server. Review information presented in documentation for your email server for any requirements that affect your deployment. For information about working with third-party email servers, see Siebel Email Administration Guide.
This topic describes factors that drive or affect performance for Siebel Email Response deployments.
Inbound email messages processed per hour. The number of inbound email messages processed per hour (or some other time period) by your communications infrastructure.
Requirements for processing outbound messages are relatively minor and are tied to inbound message volume. However, other usage of the CommOutboundMgr component or of the email system must also be considered. For example, the Send Email command can be configured to send email through CommOutboundMgr.
Volume of customer data. The total volume of customer data, including templates or categories, literature items, and so on. Template format (HTML or plain text) is a related factor.
Other factors include the size and complexity of inbound email messages and outbound replies.
Also relevant are user settings in the Outbound Communications section of the User Preferences screen, such as whether a reply contains the original message (Include Original Message in Reply setting), or whether HTML or plain text is an agent's default message format (Default Message Format setting).
|
Note: Siebel Email Response coverage in this book focuses on inbound and outbound email processing. In a multichannel environment, session communications performance issues also apply. |
Processing inbound email messages makes more demands on server resources, particularly CPU usage levels, than processing outbound messages.
Processing of inbound messages associated with a single response group must be handled on a single computer.
If inbound message volume warrants it and if multiple server computers are available to run CommInboundRcvr, CommInboundProcessor, and other components, then consider running CommInboundRcvr and CommInboundProcessor on separate computers (or computers) from other Communications Server components. Topology options for these component are different for real-time and nonreal-time processing. For more information about CommInboundRcvr and CommInboundProcessor, see Siebel Email Administration Guide.
Combining processing of messages for multiple email accounts in a single response group can make processing of inbound messages more efficient. However, if message volume is expected to grow, then limiting the number of email accounts processed by each response group will give you more flexibility to distribute processing across multiple servers, and thereby avoid processing bottlenecks.
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 Email Administration Guide, Siebel CTI Administration Guide, relevant third-party documentation, and other sources.
Each CommInboundRcvr task runs multiple threads to process inbound email. To determine the number of threads, set the parameters MinThreads and MaxThreads. If extra CPU capacity exists on a given server computer, you can run more threads for each applicable CommInboundRcvr task.
By default, CommInboundRcvr temporarily writes the content of inbound email messages into subdirectories of the Siebel Server installation directory, until the messages can be processed by the applicable response group and workflow process.
You can use parameters for the Internet SMTP/POP3 Server or Internet SMTP/IMAP Server communications driver to specify alternative directory locations for incoming email, processed email, sent email, and email messages representing certain other processing statuses. You can also set certain driver parameters to specify whether to save or delete processed email messages, for example.
You must consider the resource requirements for temporary email processing directories when you set up your system.
Do not delete messages from incoming or queued email directories. Email messages written to processed or sent directories can subsequently be deleted or saved, according to your needs.
Because of the frequency by which CommInboundRcvr processing writes to temporary email processing directories, the disk must be defragmented regularly.
For more information about email processing directories, see Siebel Email Administration Guide.
For each email work item, an activity record is created in the S_EVT_ACT table and related tables.
Attachments to such activity records, for inbound and outbound messages, are stored in the Siebel File System.
As you plan your deployment, you must consider how such records are created and managed, review the indexing and layout of applicable database tables, and review the performance impact of generating activity records.
In addition, you must consider the resource requirements for the Siebel File System for storing activity attachments.
The FSMSrvr server component generally runs on the same Siebel Server computers where you are running CommInboundRcvr and CommOutboundMgr.
|
Note: Because of the frequency by which Siebel Email Response processing writes to the Siebel File System, the disk must be defragmented regularly. |
For more information about activity attachments stored for inbound email, see Siebel Email Administration Guide.
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.
For the Internet SMTP/POP3 Server or Internet SMTP/IMAP Server communications driver, an applicable parameter is LogDebug. For more information, see Siebel Email Administration Guide.
Applicable event log levels for Siebel Email Response include those for task execution, workflow step execution, workflow process execution, and workflow performance.
