Performance Tuning Siebel Software on the Sun Platform

More documents

Recommendations

Info

7.5 <strong>Tuning</strong> the <strong>Siebel</strong> Web Server Extension (SWSE) 1. In the <strong>Siebel</strong> Web Plugin installation directory, go to the bin directory. Edit the eapps.cfg file and make the following changes: • Set AnonUserPool to 15% of . • Set the following settings in the “default” section: 5. GuestSessionTimeout to 60; this is required for scenarios where the user is browsing without logging in. 6. AnonSessionTimeout = 300 7. SessionTimeout = 300 • Set appropriate AnonUser name/passwords SADMIN/SADMIN for eChannel and Call Center (Database login) GUEST1/GUEST1 for eService and eSales (LDAP login) GUESTERM/GUESTERM for ERM (Database login) The AnonUserPool setting can vary on different types of <strong>Siebel</strong> users (call center, sales, and so on). The table below summarizes the individual eapps.cfg settings for each type of <strong>Siebel</strong> application: Call Center, eChannel, eSales and eService, used in the 10,000 users test. Parameter callcenter_enu prmportal_enu esales_enu eservice_enu AnonUserName SADMIN GUESTCP eApps2 eApps3 AnonPassword SADMIN GUESTCP eApps2 eApps3 AnonUserPool CC1=420,CC2=525, CC3=315, CC4=210 320 160 360 AnonSessionTimeout 360 360 360 360 GuestSession Timeout 60 60 60 60 SessionTimeout 300 300 300 300 Table 7.5 The SWSE stats web page is a very good resource for tuning <strong>Siebel</strong>. <strong>Performance</strong> <strong>Tuning</strong> <strong>Siebel</strong> <strong>Software</strong> on the Sun Platform Page 38
7.6 <strong>Tuning</strong> <strong>Siebel</strong> Standard Oracle Database and Sun Storage The size of the database used was approximately 140 Gbytes. The database was built to simulate customers with large transaction volumes and data distributions that represented the most common customer data shapes. Table 7.6 shows a sampling of record volumes and sizes in the database for key business entities of the standard <strong>Siebel</strong> volume database. Business Entity Database Table Name Number of Records Size in Kbytes Accounts S_ORG_EXT 1,897,161 3,145,728 Activities S_EVT_ACT 8,744,305 6,291,456 Addresses S_ADDR_ORG 3,058,666 2,097,152 Contacts S_CONTACTS 3,366,764 4,718,592 Employees S_EMPLOYEE_ATT 21,000 524 Opportunities S_OPTY 3,237,794 4,194,304 Orders S_ORDER 355,297 471,859 Products S_PROD_INT 226,000 367,001 Quote Items S_QUOTE_ITEM 1,984,099 2,621,440 Quotes S_QUOTE_ATT 253,614 524 Service Requests S_SRV_REQ 5,581,538 4,718,592 Table 7.6 7.6.1 Optimal Database Configuration Creating a well-planned database to begin with will require less tuning/reorganizing during runtime. While many resources are available to facilitate creation of highperformance Oracle databases, most tuning engineers would find themselves tweaking a database consisting of thousands of tables and indexes, piece by piece. This is both time consuming and prone to mistakes. Eventually one would end up rebuilding the entire database from scratch. The following approach provides an alternative to tuning a pre-existing, pre-packaged database: 1. Measure the exact space used by each object in the schema. The dbms_space packages provide the accurate space used by an index or a table. Other sources like dba_free_space only tell you “how much is free” from the total allocated space, which is always more. Next, run the benchmark test and again measure the space used. The difference will result in an accurate report of “how much each table/index grows during the test.” One can use this data to rightsize all of the tables, such as the capacity planned for growth during the test. Also the data can be used to figure out and concentrate on only the hot tables used by the test. 2. Create a new database with multiple index and data tablespaces. The idea is to place all equi-extent-sized tables into their own tablespace. Keeping the data and index objects in their own tablespace reduces contention and fragmentation, <strong>Performance</strong> <strong>Tuning</strong> <strong>Siebel</strong> <strong>Software</strong> on the Sun Platform Page 39
Page 1 and 2: Performance <stron
Page 3 and 4: Abstract This paper discusses the p
Page 5 and 6: 7.6.6 Oracle Parameters Tun
Page 7 and 8: 1 Tuning for Price
Page 9 and 10: 2 Siebel Applicati
Page 11 and 12: 3 Optimal Sun/Siebel</stron
Page 13 and 14: 3.1 Hardware and Software</
Page 15 and 16: 5 10,000 Concurrent Users: Test Res
Page 17 and 18: 6 Siebel Scalabili
Page 19 and 20: Cost per Siebel Us
Page 21 and 22: 7.1 Tuning Solaris
Page 23 and 24: 7.1.3 The Solaris Kernel and TCP/IP
Page 25 and 26: In the file $SIEBEL_ROOT/bin/enu/ua
Page 27 and 28: 7.2.3 Assignment Manager Tu
Page 29 and 30: MQ series parameter tuning: PERFQMG
Page 31 and 32: Investigating the Reason for the Fa
Page 33 and 34: let a Siebel proce
Page 35 and 36: Description The reason for this sym
Page 37: Parameter Scope Default Tuned Value
Page 41 and 42: 86 MB/second 57 MB/second Figure 7.
Page 43 and 44: DATA_51200K INDX_512K DATA_5120K TE
Page 45 and 46: 7.6.4 Solaris MPSS Tuning</
Page 47 and 48: Siebel Object Name
Page 49 and 50: instance_name=oramst job_queue_proc
Page 51 and 52: ORAPERF.S_PRI_LST T4 WHERE T4.PAYME
Page 53 and 54: the database during peak load. In t
Page 55 and 56: use connection pooling, so you woul
Page 57 and 58: Oracle Database Server 1. Larger th
Page 59 and 60: 160 siebelapp2_1 eSalesObjMgr_enu 1
Page 61 and 62: 9.10 To Produce a Stack Trace for t
Page 63 and 64: Count indv cuml rcnt nsec Lock Call
Page 65 and 66: 5. Once the user has stopped at the
Page 67 and 68: 10 Appendix A: Transaction Response
Page 69 and 70: eSls1_115DDSubCategory1.3 0.125 0.1
Page 71 and 72: CC3_2newSolution 0.047 0.136 3.281
Page 73 and 74: 11 Appendix B: Database Objects Gro
Page 75 and 76: S_OPTY_BU_M8 INDEX 2,334,720 S_ORDE
Page 77 and 78: log file parallel write 550,101 515
Page 79: Acknowledgements Thanks to

Performance Tuning Siebel Software on the Sun Platform

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?