Performance Tuning Guide > Tuning Customer Configurations for Performance > General Best Practices for Customer Configurations >

Miscellaneous Configuration Guidelines

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

• Avoid using sort specifications on non-indexed columns or joined columns. For more information, see Managing Database Indexes in Sorting and Searching and other relevant topics.
• Avoid the use of case insensitivity. Use of case-insensitive queries can significantly increase the possibility of performance issues due to the additional complexity required at the database level to support case-insensitive database operations.

  Prior to enabling case insensitivity, a thorough review of business requirements and performance criteria is highly recommended. In addition, if the feature is enabled, a performance test should be conducted with a full copy of the production database. The severity of the performance impact increases with the complexity of the configuration and the size of the production database.

  It is also recommended that Siebel Expert Services be engaged to optimize the configuration and review requirements. Case insensitivity is a database platform constraint and should also be reviewed with the database platform vendor.

  For more information about configuring case insensitivity for an application or for specified fields, see the Applications Administration Guide.

• Limit the use of case insensitivity for queries. Case-sensitive searches perform better than case-insensitive queries. Siebel applications are case-sensitive by default. You can enable case insensitivity either for the entire application or for specified fields. In general, the larger the database, and the larger the number of records returned by a case-insensitive query, the more that overall database performance is affected. Overall performance is also affected by the number of users who perform case-insensitive queries. End users can also force case-sensitive or case-insensitive queries.

  For more information about configuring case sensitivity for an application or for specified fields, see the Applications Administration Guide.

• 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.
• 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 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 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 displayed in the master applet on related views. The information is static and may 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 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 (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 may also slow performance. If TRUE, 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 may be used for joined tables, with a resulting savings in overhead, provided 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 may also provide guidance to end users on constructing appropriate queries.
• Cache business services. Cache business services that should be accessible at all times in a user session. To do this, set the Cache parameter to TRUE for each applicable Business Service object definition. Caching of business services has an impact on memory, as the services are cached per session. Make sure that only frequently accessed business services in a session are marked 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.