| 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 discusses tuning for Siebel Enterprise Application Integration (Siebel EAI) that might be required for optimal performance. It contains the following topics:
For more information about Siebel EAI, see the following documents on the Siebel Bookshelf:
Overview: Siebel Enterprise Application Integration
Integration Platform Technologies: Siebel Enterprise Application Integration
Transports and Interfaces: Siebel Enterprise Application Integration
Business Processes and Rules: Siebel Enterprise Application Integration
XML Reference: Siebel Enterprise Application Integration
Siebel EAI provides components for integrating Siebel Business Applications with external applications and technologies within your company. Siebel EAI works with technologies, standards, or applications that include XML, HTTP, Java, and various third-party middleware products and application integration solutions.
Siebel EAI provides bidirectional real-time and batch solutions for integrating Siebel Business Applications with other applications. Siebel EAI is designed as a set of interfaces that interact with each other and with other Siebel components.
This topic describes guidelines for maintaining acceptable performance using Siebel EAI.
General guidelines are followed by recommendations specific to Siebel EAI features such as IBM WebSphere MQ (formerly MQSeries) Transport adapter, HTTP Inbound Transport adapter, EAI Siebel Adapter, virtual business components, and Workflow Process Manager used with Siebel EAI.
Follow these general guidelines to improve overall performance for data integration and throughput of Siebel Business Applications:
Minimize round trips between systems. For example, if an integration needs to request three pieces of data, do not send a request for one piece of data, wait for the response, and then send the next request. If you need multiple pieces of data, gather the data in a single request.
Keep processing in a single session wherever possible, to avoid having to make calls between server components.
Within a session, minimize the nesting of calls between components such as workflow, scripting, and the EAI Siebel Adapter. For example, use a workflow process to sequence the calling of business services and keep scripting code in self-contained steps. Workflow subprocesses can be used to package together commonly called sequences of services.
Use alternatives to scripting, where possible. If you use scripting, then use it minimally and economically and apply documented guidelines. For more information, see "Guidelines for Siebel Scripting".
Configure business components, business services, caching, and other application functionality that supports integration processing to obtain optimal performance. For more information, see other topics in this chapter and see Chapter 12, "Tuning Customer Configurations for Performance."
Perform capacity planning for all servers that support integration processing. For sizing reviews, consult Oracle Advanced Customer Services. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.
Represent the incoming external data in the same code page and encoding that the Siebel application uses internally (UCS-2). This eliminates the need to use the Transcode business service in your workflow process, thus improving performance.
The following topics discuss specific technologies and what you can do to improve performance in each area:
This topic is part of "Guidelines for Siebel EAI Tuning".
The performance of an IBM WebSphere MQ queue is highly dependent on the disk performance of the queue manager computer and the layout of the queue's files on the disk. Test your queue with stand-alone utilities so that you have an upper boundary for the performance that can be expected in a live application.
To achieve higher throughput, consider the following options:
Run multiple MQ Receiver tasks. Run multiple MQ Receiver tasks in parallel on the same computer or across several computers. The optimal number of MQ Receiver tasks depends on the transaction type.
|
Note: This guide refers to MQ Receiver, where the actual Siebel Server component that you are using might be MQSeries Server Receiver (alias MqSeriesSrvRcvr) or MQSeries AMI Receiver (alias MqSeriesAMIRcvr). |
The default number of MQ Receiver tasks is 1. You can set this to 10 or more, depending on the nature of your transactions and on available server capacity.
Adding MQ Receivers is generally most helpful for handling CPU-bound transactions, where the dequeuing rate is low and MQ contention is not experienced.
Sometimes contention is still experienced after adding MQ Receiver tasks, such as when multiple MQ Receivers connect to the same MQ queue manager or queue. See the next item for more information.
Run multiple MQ queue managers. If you experience diminishing returns from adding MQ Receiver tasks, then you might benefit from running additional MQ queue managers. Doing so can help to reduce contention of MQ resources stored in physical folders on disk.
Turn off persistent queuing if it is unneeded. Performance issues for non CPU-bound transactions or for persistent queuing are often related to MQ contention, which is not helped by adding receivers. If you do not require persistent queuing, then turn it off.
Persistent queuing is significantly slower than normal queuing for WebSphere MQ. If you do not use this feature, however, then messages will be lost if the queue manager goes down.
Set Maximum Number of Channels parameter. Set the Maximum Number of Channels parameter in the WebSphere MQ queue manager to be greater than or equal to the maximum number of simultaneous clients that you have running.
In addition, you can take specific actions to improve WebSphere MQ Transport performance for outbound and inbound transports, as detailed in this topic.
For inbound WebSphere MQ messages, run multiple MQ Receivers in parallel to increase throughput.
Caching of WebSphere MQ Transport business services can improve outbound performance by eliminating the need to connect to the queue for each message. Caching is disabled by default because it is not usable in every situation. Follow these tips to enable caching:
Cache in client sessions only. Do not use caching if your transport will be called within the Workflow Process Manager (WfProcMgr) component. The threading model of this component is not compatible with the WebSphere MQ APIs.
To enable caching for a business service, set the Cache property to TRUE in Siebel Tools, then recompile the SRF file.
If you need to call the WebSphere MQ Transport in Workflow Process Manager and in a client session, then make a separate copy of the service (one cached and one uncached) for each situation.
Caching occurs on a per-queue basis and only one connection is kept open at a time. If a single session is going to talk to multiple queues, then consider making a copy of the transport for each outbound queue.
|
Note: See your IBM WebSphere MQ documentation for performance and sizing guidelines. |
You can get detailed performance tracing of the WebSphere MQ Transport by setting the EAITransportPerf event to level 5.
You can set this event level for multiple Siebel Server components that play a role in Siebel EAI functionality, including Workflow Process Manager (WfProcMgr), EAI Object Manager (EAIObjMgr), MQ Receiver, or other components. For example, you can use srvrmgr to set the event level for MQ Receiver:
change evtloglvl EAITransportPerf=5 for comp MqSeriesSrvRcvr
This topic is part of "Guidelines for Siebel EAI Tuning".
The HTTP Inbound Transport supports two modes, session mode and sessionless mode:
In session mode, the session stays live until a logout call is made
In sessionless mode, logging in and logging out occur automatically for each request
Use session mode whenever possible, because the time required to log into the application is usually significantly longer than the time required to process an average request.
You can also use the SessPerSisnConn component parameter to control the number of sessions sharing the same physical Siebel Internet Session Network Application Programming Interface (SISNAPI) connection between the Web server and the EAI Object Manager.
Setting this parameter to 1 provides a dedicated physical connection for each Siebel session. The default value is 20, to allow up to 20 sessions to share the same SISNAPI connection. For the EAI Object Manager, it is recommended that you set SessPerSisnConn to 1. If setting SessPerSisnConn to 1 results in an excessive number of sessions, then consider increasing the value of SessPerSisnConn or provide additional hardware resources.
You can change this parameter using srvrmgr at the Enterprise or Server level. For example, to set the parameter at the Enterprise level for the EAI Object Manager, you enter the following command:
change param SessPerSisnConn=1 for compdef eaiobjmgr_enu
|
Caution: If you setSessPerSisnConn to a value of 1, then you must set the parameter ConnIdleTime to a value other than -1 (its default value). Otherwise, this combination of settings might cause the Web server to stop running. |
For more information about configuring SessPerSisnConn, see "Configuring SISNAPI Connection Pooling for Siebel Application Object Managers".
This topic is part of "Guidelines for Siebel EAI Tuning".
Use the techniques described here to improve the EAI Siebel Adapter performance and throughput.
Avoid scripting events on business components used by the EAI Siebel Adapter. Perform any scripting task either before or after the EAI Siebel Adapter call, rather than within it. For general scripting guidelines, see also "Guidelines for Siebel Scripting".
Disable logging for performance-critical processes that are functioning correctly to gain about 10% faster performance. You can disable logging for the EAI Object Manager (or other applicable server components, such as MQ Receiver) by setting the BypassHandler parameter to TRUE.
The size of an integration object and its underlying business components can have an impact on the performance of the EAI Siebel Adapter. To minimize this impact, you can:
Consider copying business objects and business components and modifying them to remove any elements (such as scripts, joins, multi-value fields, user properties, and so on) that you do not require in the Siebel EAI context. Base your integration objects on these relatively streamlined object definitions. Verify that user keys on your integration objects make effective use of indexes when queries are performed.
Inactivate unneeded integration components and integration component fields in your integration objects. Activate only the components and fields needed for message processing, according to your business needs.
Inactivate unneeded fields for each underlying business component. For fields that are unneeded, if Force Active is set to TRUE, then set it to FALSE. Setting Force Active to FALSE prevents the EAI Siebel Adapter from processing these fields. If you do not inactivate these fields, then the adapter processes them even when they are not actually included in the integration object.
For more information, see "Limiting the Number of Active Fields".
Requests to the EAI Siebel Adapter eventually generate SQL to be executed against the Siebel database. By setting the event SQL to level 4 in the component running in the EAI Siebel Adapter, you can get a trace of the SQL statements being executed, along with timings for each statement, in milliseconds.
You can get timings for each EAI Siebel Adapter operation by setting the event EAISiebAdptPerf to 4 or 5. Do this to correlate the EAI Siebel Adapter calls with their associated SQL.
After you have this information, look through the logs to find any SQL statements taking significantly longer than average. To improve the performance of such statements, look at the business component (perhaps eliminating unnecessary joins and fields) or at the physical database schema (perhaps adding indexes).
|
Note: The overall timing across operations (equivalent to theTotalTimeForProcess event) cannot be determined by adding the individual logged values associated with the EAISiebAdptPerf event, because the EAI Siebel Adapter requires some additional overhead. Overhead is greater when EAISiebAdptPerf is set to a high value. Set this event to a lower value for a production system for optimal performance. |
A common technique to improve throughput is to run multiple instances of the EAI Siebel Adapter in parallel.
For the MQ Receiver, you do this by running multiple receiver tasks. For more information, see "Improving IBM WebSphere MQ Transport Performance".
For the EAI Object Manager, you do this by setting the MaxTasks, MaxMTServers, and MinMTServers parameters, in order to run more threads (tasks) on more multithreaded processes for the EAI Object Manager component. Also start multiple simultaneous HTTP sessions. There is little interaction between each instance of the EAI Siebel Adapter.
If the Siebel database server is large enough, then almost linear scalability of the EAI Siebel Adapter is possible until either the limits of the CPU or the memory limits of the Siebel Server are reached.
|
Caution: If two sessions attempt to simultaneously update or insert the same record, then one will succeed and one will produce an error. Therefore, when running the EAI Siebel Adapters in parallel, you must prevent the simultaneous update of the same record in multiple sessions. You can prevent this by either partitioning your data or retrying the EAI Siebel Adapter operation where the error occurs. |
The EAI Siebel Adapter caches business objects by default. The default cache size is five objects. Using caching, subsequent runs on the adapter are significantly faster because the business objects do not need to be re-created for each run.
Use the BusObjCacheSize parameter on the EAI Siebel Adapter to change the size of the cache, if required. However, the five-object cache size is enough for most purposes. Making this number too large creates an unnecessarily large memory footprint.
This topic is part of "Guidelines for Siebel EAI Tuning". Because users must wait for the virtual business component (VBC) response to display the GUI component for the integration on their screens, this type of integration is especially sensitive to latency. To improve virtual business component performance when your integration has multiple requests, put the requests for a given system in a single batch.
This topic is part of "Guidelines for Siebel EAI Tuning". It discusses performance issues for the Workflow Process Manager component. For more information about Siebel Workflow performance, see Chapter 7, "Tuning Siebel Workflow for Performance." Also see Siebel Business Process Framework: Workflow Guide.
Workflow Process Manager is a task-based server component. A new thread is created for each request. However, sessions for Object Manager components (such as EAI Object Manager or Siebel Application Object Managers) that can invoke workflow processes are cached and reused for subsequent requests. When sizing a system, consider the maximum number of workflow tasks that you expect to have active at a given time. This determines the maximum number of Object Manager sessions that Siebel applications create. In general, creating smaller workflow processes is recommended. If you cannot avoid creating a large workflow process, then divide the workflow process into subprocesses.
The exact CPU and memory consumption of each task depends on the actions performed in your workflow processes. To estimate CPU and memory consumption in your production environment, run a single task, measure its resource consumption, and make an estimation based on your maximum concurrent sessions. Take session caching into account when making these measurements.
If you need a large number of sessions, then you might want to run Workflow Process Manager on multiple Siebel Server computers. You can then use Siebel Server load balancing to load-balance requests across the Siebel Servers. If you plan to run a significant number of tasks per server (such as 100 or more), then you might also want to run multiple multithreaded processes.
If you are going to run several different types of workflows, then run each type in a separate process. This makes it easier to monitor the overall CPU and memory usage of each process type.
The number of multithreaded processes and the number of tasks per process are controlled through the parameters MaxMTServers (Maximum MT Servers), MinMTServers (Minimum MT Servers), and MaxTasks (Maximum Tasks).
|
Note: These parameters are per Siebel Server. For example,MaxMTServers refers to how many multithreaded processes to run on each Siebel Server computer. For details, see Siebel System Administration Guide. |
You can get performance tracing of workflows by setting the event WfPerf for the component in which your workflow is running. Setting the event to level 4 gives timing for the execution of the overall process. Setting the event to level 5 provides timing for each step as well.
You can set this event level for any Siebel Server component that invokes a workflow process as part of Siebel EAI functionality. For example, to set this event level for the MQ Receiver using srvrmgr, enter the following:
change evtloglvl WfPerf=5 for comp MqSeriesSrvRcvr
These events can be useful not just for measuring workflow performance but also for measuring the performance of business services executed within these workflows.
This topic is part of "Guidelines for Siebel EAI Tuning". Review the following issues for applicability to your deployment, for optimizing Siebel EAI performance:
Check disks on the computer. Do a preliminary test on the queue manager that you are using to see how many sends and corresponding receivers it can support per second (use multiple drivers). Queue vendors such as IBM WebSphere MQ provide test programs that you can use to drive these and determine how much the queue itself can scale. The speed of the disks on the computer is important.
Optimize messages. In the messages, reference only the columns that you require.
Create smaller business components. Messages might use only a small portion of the actual business components.
Create copies of the business components that you are using. In the copies, keep active all fields used by the optimized integration object or otherwise used for correct processing of messages (like the visibility fields or status fields). Deactivate all other fields. Also deactivate the join definitions and multi-value links (MVLs) that are not needed for processing of the messages.
The original business components are often large and complex and contain elements that you will not need for your integration purposes. Use the smaller business components and business objects and links created when creating the optimized integration object.
Business components can have fields with Force Active set to TRUE. Check this property for fields in the business components, using Siebel Tools. If the fields are not needed, then set Force Active to FALSE.
Set user property All Mode Sort to FALSE. Set the user property All Mode Sort to FALSE for optimized business components (if not already set). Do this only for the smaller business components created for use with Siebel EAI, because this user property changes the order in which rows are retrieved, which might not be appropriate or normal clients. For more information about All Mode Sort, see Siebel Developer's Reference.
Optimize database queries. Review queries generated by the receiver process and verify that they are optimized.
Turn off logging. Turn off server-side logging that you do not require.
