Improving the performance of Siebel BI Publisher Report generation
1) Increasing the amount of heap memory available to the Java Virtual Machine (JVM)
Increasing the memory available to the JVM can improve the performance of the report generation and ensure that this error is not encountered.
"C:\OraHome_1\jdk\bin\java" -XX:MaxPermSize=128m -Xms512m -Xmx512m -Duser.language=en -Duser.dir=C:\OraHome_1\oc4j_bi\bin -Duser.country=US -jar "%OC4J_JAR%" %CMDARGS%
OS
|
Memory Value
|
Windows (32-Bit)
|
Any value of up
to 1.4GB (based on available RAM)
|
Windows
(64-Bit)
|
1.4 GB or higher
(based on available RAM
|
2) Changing the Server Request Processor DB Polling Interval
By decreasing the polling interval the Server Request Processor can check the S_SRM_REQUEST table more regularly thereby reducing the period before the request processing is started. Once the change has been made it is necessary to shutdown and restart the affected Siebel Server before the change will take effect.It is recommended that this change be made only on the Siebel Servers hosting the XMLPReportServer component as this change will result in an increased number of queries being issued against the S_SRM_REQUEST table in the database.
change param PollIntvl=1 for comp SRProc
3) Minimize the size of Integration Objects/Components
An excessive number of unrequired fields in the report will lead to increased data generation times from the XMLPReportServer component and will result in an increased data file size for BI Publisher to process.
4) Minimal Force Active fields on BC-
Ensuring that a minimal number of fields are flagged as Force Active will help to ensure that the number of fields being returned when querying against the Integration Component for report generation is further reduced.
5) XMLPReportServer PreloadSRF parameter to TRUE
Prelolading the SRF into the process ensures that any performance overhead during the SRF load is encountered during component startup and not during report processing. This parameter is listed under Advanced tab.
6) Inactive Web Services not used in Enterprise
Due to Bug 10587893 at present the component will load all of the active webservices configured in the enterprise rather than just those which it may access, such as PublicReportService or PublicReportService_v11. This leads to a performance overhead during the first report request for any process as these can take a significant period of time to load. In order to reduce the impact of this loading process review the webservices configured as 'Active' in the Siebel Enterprise through the Administration - WebServices > Outbound Webservices and Inbound Webservices views. Set any webservices which are not used in the enterprise to 'Inactive'..
7) Minimize logging levels on all report generation components
This will include the requesting Object Manager, the XMLPReportServer component, the EAI Object Manager, the File System Manager component, and the BI Publisher Server itself.
8) Eliminate any un-necessary scripting during report generation
9) Create Separate Named Datasource For Siebel BI Publisher Reports With Large Data Volume
Generating Large Reports (over 10,000 records) - When running report generation there may be scenarios in which more than 10,000 records need to be retrieved. The standard ServerDataSrc within the Siebel Enterprise has a row limit of 10,000 for any single query and therefore in order to support large report generation a custom data source is required without this restriction. The following post covers this requirement in detail :
How To Create Separate Named Datasource For Siebel BI Publisher Reports With Large Data Volume
