Tuning Oracle Configurator for better performance Author: Siva Pola Date: 20 May 2009 Revision: 0
Table of Contents Table of Contents... 2 Executive Overview... 3 Factors that impact performance... 3 Modeling... 3 Configurator Extensions Design... 3 Configurator Profile Options... 4 Configurator Setup : CZ_DB_SETTINGS... 4 Hardware Configuration and Load balancing... 4 Webserver Configuration Files... 4 Bouncing Apache... 5 Purge Strategy and Re Indexing... 5 Tools used to analyze the performance... 6 Configurator Performance Testing... 6 Transactions to measure... 6 Tools used to measure performance Load Runner... 6 Test Methodology... 6 Conclusion... 7 Page 2 of 7
Executive Overview This document addresses the factors that impact the runtime performance of the Configurator, the transactions that need to be measured for performance and the mechanism to tune these factors and measure the improvement in performance. This document does not address the build time performance of Configurator. Factors that impact performance Here are some of the factors that impact the performance Modeling Configurator Extensions Configurator Profile Options Configurator CZ_DB_SETTINGS Web Server Configuration Scheduling Apache Bounces Purge Strategy and Rebuilding Indexes after Purge Modeling There are a number of guidelines for better performance. We should make a trade off between the performance and the user experience / functionality. The list is exhaustive, Please refer to modeling guide for details. Spend considerable amount of time designing BOMs / Model structure. Avoid large BOMs if possible. Instead of creating 1000 options in one option feature, create ten option features each with 100 options. Analyze the models and consolidate them in to a smaller set of models by combing models making use of common functionality across the models. Use the reference models where ever possible. Configurator Extensions Design Configurator extensions have to be written with performance implications in mind. Avoid traversing the model structure where ever possible. Do not use get child by name method where ever possible. Instead bind the required node directly. Make sure you close all JDBC connections and free the resources in your extensions. Disable logging in runtime. Instead write your errors to a custom database table in case of an error. Do not use global event scope unless it s required. Page 3 of 7
Configurator Profile Options Profile Option Recommended Value Notes CZ: BOM Tree Expansion State One Level This is the default value, and it should provide the best load-time performance. This profile option is used only by the CZ: Generic Configurator UI Max Child Rows CZ: Include Unchanged Install Base Items CZ: Only Create CZ Config Items for Selected Nodes generic Configurator User Interface. 50 This is the default value, but specifying a smaller value may improve load-time performance. This profile option is used only by the Generic Configurator User Interface Yes Yes This profile option is used only used when reconfiguring installed instances. Improves performance when saving large configuration models, or a configuration that has many initial BOM Model instances. BOM: Configurator URL of UI Manager CZ: Skip Validation Procedure The URL of a JServ that is running Oracle Configurator. The name of a PL/SQL function that you define If load balancer is used, this should refer to the appropriate server. Applicable when batch validation is not performed. Configurator Setup : CZ_DB_SETTINGS At runtime, the user need not perform any action as this Configurator extension is called on save. AltBatchValidateURL Applicable when batch validation is not performed. UtlHttpTransferTimeout - Applicable when batch validation is not performed. Hardware Configuration and Load balancing It s recommended that the database and apache server hosting the Configurator hosted on two different machines. It s recommended that you have multiple apache servers with a load balancer to host the Configurator servlet. The hardware to be used and the configuration of web server depends on the number of concurrent users Webserver Configuration Files 1) httpd.conf (Location : $APACHE_TOP/Apache/conf) Include $APACHE_TOP/Jserv/etc/jserv.conf Page 4 of 7
2) jserv.conf (Location : $APACHE_TOP/Jserv/etc) ApJservVMTimeout 1800 (30 minutes) Include jserv.properties 3) jserv.properties (Location : $APACHE_TOP/Jserv/etc) Include cz_init.txt Apache Settings if not using native threads wrapper.bin.parameters= -Xmx512M -Xms512M -XX:MaxPermSize=512M -XX:NewSize=60M -XX:MaxNewSize=120M 4) cz_init.txt (Location : $APACHE_TOP/Jserv/etc) wrapper.classpath=custom_class_path cz.uiserver.lazyload=0 (???) cz.uiserver.dio_share=true cz.uiserver.heartbeat_interval=30000 cz.uiserver.poll_timeout_applet=30000 cz.uiserver.check_heartbeat_timeout=90000 cz.activemodel=/nolp /nodp /noatp cz.uiservlet.pre_load_filename=$apache_top/jserv/etc/init_msg.txt (Optional) 5) cz_init.txt (Location : $APACHE_TOP/Jserv/etc) Bouncing Apache Example : <initialize> <param name="database_id">dbc_filename</param> <param name="gwyuid">applsyspub/pub</param> <param name="user"apps</param><param name="pwd">apps</param> <param name="ui_type">jrad</param> <param name="context_org_id">5</param> <param name="model_id">1234</param> <param name="calling_application_id">671</param> </initialize> It s recommended that web server is bounced at scheduled intervals to free the memory and resources used by JVMs. Purge Strategy and Re Indexing It s recommended to have a purge strategy in place to purge the runtime data in a timely manner. Runtime data is saved in CZ_CONFIG_HDRS, CZ_CONFIG_ITEMS, CZ_CONFIG_INPUTS Delete the data related to closed quotes or use some criteria to determine how much of the old data needed. Create a custom program to purge this data. Rebuild the indexes on the table after the purge was run. Page 5 of 7
Tools used to analyze the performance Few of the tools are very helpful to analyze the performance. Tools like JPROBE to monitor the memory used by JVMs. Custom tools which parse the log files to generate the reports of how many Configurator extensions were called. Configurator Performance Testing Transactions to measure The following transactions can be measured using a tool like Load Runner simulating the average number of users Transaction Name Oracle Login Load a Configuration Save Configuration Reconfigure Copy a Configuration Summary Page Time to navigate to a different page Acceptable Service Level Notes Tools used to measure performance Load Runner Details of setting up Load Runner for testing Configurator can be found in the Configurator Performance Guide. Test Methodology The best way to perform the testing it to run the test and measure time it takes for each transaction. Modify one or other factor to improve the performance and run the tests in the next iteration. Repeat the cycle till the transaction times meet the acceptable service level objectives. Page 6 of 7
Conclusion It is possible to improve the performance in good measure by following these guidelines in methodical order and measuring the performance after each change. Page 7 of 7