Bookshelf v7.5.2: Other Performance Bottlenecks

Siebel Tools Reference > Performance Improvement >

Other Performance Bottlenecks

The following are some additional sources of poor performance:

Large 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 applet, or you can define a default predefined query on the view.

Search specification on a non-RDBMS-supported calculated field. Calculated fields utilize functions that may or may not be supported by the underlying relational database system. If the RDBMS supports the function, it will have algorithms for performing the calculations efficiently and will return the calculated values with the result set. If the function is not supported in the RDBMS, the Siebel application client may have to rescan the entire result set to perform the desired calculation, considerably increasing the time it takes to obtain the results of the query. The difference is that in the one case the calculations can take place before the results are returned, and in the other, they have to be performed in memory on the client.

NOTE: Even if the calculated field is supported at the RDBMS level, there may be other reasons why a search specification on a calculated field may result in poor performance, such as the lack of an index (for example, when using the LIKE function) supporting the search specification. See Database Indexes in Sorting and Searching.

Too many 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.

Writing scripts on applet and business component Change Record events. Scripts written on these events should be very simple. Complex or I/O-intensive operations in these events will adversely affect performance.

Adding Siebel VB code to event routines. Using Siebel VB code, such as loops, in event routines can cause performance problems.

Number of joins, extension tables, and primary ID fields in a business component. Joins degrade performance by causing an extra row retrieval 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 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.

Number of fields in a business component. There is no set limit on the number of fields in a business component or 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.

Use of EXISTS, Max, or Count functions in a search. Using the EXISTS, Max, or Count functions in a search specification causes sub-queries within the main query, thus slowing performance.

Use of Force Active property in fields. When fields in the business component have TRUE settings in the Force Active property, performance may be slowed. The Force Active setting of TRUE indicates to the system that it must obtain data for the field every time the business component is accessed, even though the field is not displayed in the current applet; this adds the field to the SQL query each time. The Force Active property affects performance more significantly when fields are based upon MVLs or joins, because the Siebel application has to create the relationships in the SQL query in order to retrieve these columns.

While Force Active is necessary in some cases, it is often sufficient to put a control or list column on an applet and "hide" it by setting the Visible property to FALSE. This way the data does not have to be retrieved every time the business component is instantiated, only when the relevant applet is used.

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 of outer joins instead of inner 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 to FALSE. This improves the performance of queries that use the join.

Cascade Delete set in a many-to-many link. 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 Inter Table setting. The Cascade Delete property in such a link must be set to NONE.