General Performance Guidelines for Customer Configurations

This topic provides some general guidelines for customer configuration using Siebel Tools.

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.

Siebel Business Application architecture has been designed and tuned for optimal performance, making use of features such as database indexes, data caching, RDBMS cursors, efficient SQL generation, native database APIs, and so on. However, custom configurations can have various potential performance pitfalls, the impact of which might be amplified in environments with large databases and wide data distribution across servers. Follow the guidelines presented here and in other documentation to avoid such problems.

The following are some miscellaneous configuration guidelines for maintaining optimal performance:

Avoid using sort specifications on nonindexed columns or joined columns. For more information, see "Managing Database Indexes in Sorting and Searching" and other relevant topics.
Avoid overly complex user interface configuration. In general, do not include a large number of applets per view (generally include no more than four applets), or a large number of fields per applet.
Use the performance of standard Siebel views as a benchmark. Custom configurations are customized versions of the standard Siebel Business Applications configuration. The Siebel data model is designed to have good performance for the expected standard queries for the standard views. If a custom view is slow, then verify the performance of the most appropriate standard view for that custom view. For example, if your custom version of the All Accounts view is slow, then verify the performance of the standard All Accounts view. Use this as a benchmark for the custom view and something to compare the performance to.
Limit the number of business components in a view. An excessive number of different business components used in applets in a view can slow down the display of data upon entry into that view. This is because each of the applets must be populated with data.
Limit the number of virtual business components in a view. Avoid using more than two virtual business components in a single view.
Limit the number of fields in business components or applets. There is no set limit on the number of fields in a business component, or the number of list columns in a list applet. However, a business component with too many active fields will have degraded performance. Also, in some database systems it is possible to generate a query that is too large to be processed. See also "Limiting the Number of Active Fields".

In particular, reduce the number of fields that are displayed in the master applet on related views. The information is static and might not be necessary. Additional space will be available on the view for supporting data without users needing to scroll. (This will also provide a usability benefit.)

End users can reduce or increase the number of fields that are displayed in a list applet, by using the Columns Displayed menu option. However, it is best to provide an optimal default number of visible fields for each applet. It is also best to provide the minimum required total number of fields, including those that are hidden by default.
Limit the number of required fields. Required fields are always retrieved from database queries. Consequently, limiting the number of required fields (that is, fields for which the Required user property is TRUE) in your business components can improve performance. See also "Limiting the Number of Active Fields".
Limit the number of records returned. To limit the number of records returned for a business component, you can add a search specification to the business component or to applicable applets or links, or you can define a default predefined query on the view.
Limit the number of joins, extension tables, and primary ID fields in a business component. Joins degrade performance by causing an extra row retrieval operation in the joined table for each row retrieval in the main table. Extension tables and primary ID fields also use joins, although implied rather than explicitly defined, adding a row retrieval operation for each.

The more joins, extension tables, and primary ID fields defined in a business component, the higher the number of row retrievals required in tables other than the main table, with a corresponding performance degradation.
Limit the use of Link Specification property in fields. TRUE settings in the Link Specification property in fields can also slow performance. If TRUE, then the field's value is passed as a default value to a field in the detail business component through a link.

This is necessary if the master business component has a link relationship (in the current business object) with one or more detail business components, and these detail business components utilize the Parent: expression in the Pre Default Value, Post Default Value, or Calculated Value properties in any fields. The master business component must pass the field value to any detail records displayed.

As with the Force Active property, fields with the Link Specification property set to TRUE will be retrieved every time the business component is queried.
Use inner joins rather than outer joins. Inner joins can be used for joined tables, with a resulting savings in overhead, provided that you are guaranteed that all foreign key references are valid.

For example, when the join is from a detail business component to its master, you are guaranteed of the existence of the master. You can configure the join as an inner join by setting the Outer Join Flag property of the Join object definition to FALSE. This improves the performance of queries that use the join. In general, avoid using double outer joins.
Configure Cascade Delete appropriately for many-to-many links. The Cascade Delete property in a Link object definition must be correctly configured for use in a many-to-many link, or the first insertion or deletion in the association applet will be abnormally slow. A link object definition used in a many-to-many relationship is one that contains a non-NULL value for the Inter Table property. The Cascade Delete property in such a link must be set to None.
Remove unneeded sort buttons. Remove sort buttons from list columns in list applets where this capability is not required.
Reduce the need to scroll in a view. Whenever possible, design views that do not require scrolling. (This will also provide a usability benefit.)
Provide tuned PDQs. Provide tuned PDQs (predefined queries) that address most user requirements. Doing so reduces the likelihood of users creating undesirably complex queries. You might also provide guidance to end users on constructing appropriate queries.
Cache business services. Cache business services that must be accessible at all times in a user session. To do this, set the Cache property to TRUE for each applicable Business Service object definition. Caching of business services has an impact on memory, because the services are cached per session. Make sure that only frequently accessed business services in a session are marked as cacheable.
Avoid calculated fields that do Counts and Sums. Reduce, where possible, the use of calculated fields that do Counts and Sums. If such fields are active, they will cause performance degradation.