Chapter 4   Performance Tuning and Monitoring


After installing the iPlanet Market Maker software, a number of performance tuning steps can be carried out to ensure the best performance of the application.

This chapter contains the following sections:

• Testing Scenarios

• Tuning the System

• Tuning iPlanet Directory Server

• Tuning Oracle

• Tuning the iPlanet Application Server

• Tuning iPlanet Market Maker

• Monitoring Performance

Testing Scenarios

---

The performance and tuning recommendations in this guide are based on findings from tests conducted in our test labs to measure the performance of the iPlanet Market Maker software in different scenarios. Performance tests were conducted on individual modules and on mixed scenarios. Mixed scenarios simulated the realistic conditions of the initial phase of deployment as well as operation in a production environment. The tests focused on the most commonly used functions in each module.

The performance tests were conducted on different sizes of catalog and community. Some examples of test cases:

• Catalog search

• Catalog browse

• Community - Registration

Tuning the System

---

The following sections contain information on tuning your system to improve performance:

• Tuning Solaris Kernel Parameters

• Configuring Memory

• Configuring Disks

Tuning Solaris Kernel Parameters

To achieve better performance and scalability, the Solaris operating system can be tuned. These settings should be made on the client iPlanet WebServer/iPlanet Market Maker hosts. The following settings should be made in the system file so that the settings become effective with the current values whenever the server is booted:

Set rlim_fd_max=8192

Set rlim_fd_cur=8192

Set sq_max_size=0

Run the following settings from the command line whenever the system is rebooted (they can be grouped and run as a script file):

ndd -set /dev/tcp tcp_time_wait_interval 60000

ndd -set /dev/tcp tcp_conn_req_max_q 1024 (Only for Solaris 2.8)

ndd -set /dev/tcp tcp_conn_req_max_q0 4096

ndd -set /dev/tcp tcp_ip_abort_interval 60000

ndd -set /dev/tcp tcp_keepalive_interval 900000

ndd -set /dev/tcp tcp_rexmit_interval_initial 3000

ndd -set /dev/tcp tcp_rexmit_interval_max 10000

ndd -set /dev/tcp tcp_rexmit_interval_min 3000

ndd -set /dev/tcp tcp_smallest_anon_port 1024

ndd -set /dev/tcp tcp_slow_start_initial 2

ndd -set /dev/tcp tcp_xmit_hiwat 32768

ndd -set /dev/tcp tcp_recv_hiwat 32768

Configuring Memory

Sizing the RAM for your configuration depends on the implementation scenario you choose. The only reliable way to estimate your memory requirements is through stress testing the system with the user loads and user actions you would expect in a real world scenario.

Each server type in the production systems have different forces that drive the memory requirements. Consider the following factors to configure memory across different servers and perform stress test to monitor the memory utilization.

• The proxy tier utilizes memory for caching and SSL decryption. The decryption proxy servers utilize memory for decrypting the content sent to and returning from the web server layer. The size of the memory which can only be determined by stress and performance testing should be tailored to the throughput of the proxy server layer.

• The static server is responsible for caching the static content of the market place. The more static content you have that can be cached, the more you will benefit from more memory.

• The application server tier derives its memory requirements more directly from the application itself. This is determined by the marketmaker in addition to the customization that is made to the product in your installation. As you increase the number of users on the system, the memory requirements for the application server increase. As a general rule, most application servers are configured for 512MB to 1 GB of RAM per CPU. Your selection of the appropriate amount of RAM will be contingent on your performance testing results.

• The iPlanet Directory Server benefits a great deal from memory and so it is important that the memory be sized appropriately for your installation. The memory in the iPlanet Directory Server used for caching is able to deliver very high levels of performance when ample memory is available. Refer to the iPlanet Directory Server documentation for latest sizing instructions.

• The Oracle 8.1.7 / 9i server also benefits greatly from appropriate amounts of memory. Since the sizing of the Oracle 8.1.7 / 9i server can be very complex, consult your DBA for information on sizing the memory on the server.

Refer to "Monitoring Performance" to learn how to observe memory utilization. A full listing on all the processes with the processor numbers and their memory utilizations can be helpful in determining the memory configuration. A few tips:

• Running the vmstat command will give you the information about the free and available memory that can be utilized optimally.

• At the application server layer, if you are running short of memory, you can down size JVM heap, taking care not to go below 256MB.

• On the database machine, give Oracle as much memory as you can to limit or avoid swapping.

For more details on configuring the memory, refer to the administrator's guides of the individual server applications.

Configuring Disks

Depending on the size of the database, read/write loads can be heavy. Placing the Oracle tablespaces and LDAP database on a single disk will result in queueing the read and write operations, causing undue delay in response. Separating and distributing the Oracle tablespaces among multiple disks or an array of disks enables simultaneous (parallel) access to the database, which will solve the problem. The iPlanet Market Maker software is configured to work with separate Oracle data and index tablespaces for each module, such that the tablespaces can be distributed among separate disks or disk arrays. For example, the Auction, and Catalog modules have separate data and index tablespaces. While bidding on auctions, a user accesses the Auction tables, the Catalog tables, and the Common tables individually. If the tablespaces for the data and their indexes are placed in separate disks or disk arrays, they can be accessed simultaneously, which improves response time considerably. Similarly, LDAP database files, index files and transaction logs can also be distributed among multiple disks to achieve better response times during Community-Registration activity.

Based on our performance analysis, the following general guidelines are recommended:

• Disk array striping—Striping the group of disks creates a logical mount point. These striped logical disk units can be used in place of singular disks for better performance. Hardware and software striping can be used to get optimal performance by striping the groups of disks. The disk arrays can be mirrored by using the operating system's mirroring or RAID solutions.

• I/O distribution—Distribute the I/O evenly among the controllers.

For specific instructions on how to distribute Oracle and LDAP database among multiple disks, refer to the following sections:

"Distributing the Write Load Among Multiple Disks"
"Distributing the Tablespaces Among Multiple-Disks"

Tuning iPlanet Directory Server

---

To improve response times, read and write performance of the LDAP and Oracle databases must be configured. The following sections describe how LDAP and Oracle can be configured to achieve better performance. Also refer to iPlanet Directory Server documentation and "Oracle 8.1.7 / 9i Designing and Tuning for Performance".

Improving the LDAP Read Performance

LDAP maintains two levels of cache. Improved LDAP performance can be achieved by tuning these two-level caches:

• Database cache

• Entry cache

The basic rule for sizing these caches is:

Dedicate 75% of your cache memory to dbcachesize and 25% to the entry cache size. For example, if you have 500 MB RAM available for caching the directory, tune the caches as described below.

Tuning the Database Cache

The database cache is the lower-level cache, which caches the pages from the database. The size of the database cache is set in terms of memory size in the file slapd.ldbm.conf in the config directory of the LDAP instance home.

1. Calculate the database cache as follows:

   The memory used by the database cache = 500 * 75% = 375MB, and the overhead associated with cache management = 25%; therefore the setting should be = 375MB / 1.25 = 300 MB

2. Apply the caveats as follows before accepting the results:
   • If the result is larger than 1.6 GB, reduce it to 1.6 GB (the maximum dbcache size).

   • If the result is smaller than the total size of the database indexes (calculated by adding the sizes of all *.db2 files in the database directory and deducting the size of the file, id2entry.db2), increase it to match the size of the indexes, taking care not to exceed available memory.

3. Set the size in this file:

   <iPlanet-home>\slapd-<instance name>\config\ slapd.ldbm.conf

Tuning the Entry Cache

The entry cache is the higher-level cache, which caches the most recently used entries from the directory. The size is set in the slapd.ldbm.conf file in the config directory of the LDAP instance home, in terms of the number of entries it should hold rather than a memory size.

1. Calculate the entry cache as follows:

   Required Entry size = 1000 bytes per entry.

   Memory used by entry cache = 500 * 25% = 125MB;

   Available memory including overhead = 125 / 1.25 = 100MB;

   Therefore, the setting should be = 100,000,000 bytes / 1,000 bytes per entry = 100,000 entries.

2. Set the size in this file:

   <iPlanet-home>\slapd-<instance name>\config\ slapd.ldbm.conf

Improving the LDAP Write Performance

LDAP write performance can be improved by the methods discussed in the following sections:

• Setting the db_home_directory

• Distributing the Write Load Among Multiple Disks

• Disabling Durable Transactions

• Setting the ALL_IDS_THRESHOLD

Setting the db_home_directory

Making this setting reduces the LDAP-write related response times considerably. The standard deviations in the response times would decrease considerably. Though the average response times are not considerably affected, this setting would reduce isolated peaks observed in the LDAP write timers thus reducing the chances of a few users being timed out during the registration process under load.

This method can be used if the following symptoms are observed from vmstat and iostat on the LDAP host:

• The operating system seems to flush pages endlessly. This flushing can be so excessive that performance of the entire system is severely degraded.

• The disk is heavily used (more than 1MB per second of data transfer).

• There is a long service time (more than 100ms).

Two additional conditions where this setting may be necessitated are:

• The database cache size is around 100 MB or more.

• There is mostly write activity going on the LDAP host.

To set the db_home_directory:

The directory referenced by db_home_directory must be a subdirectory of a file system of type tempfs (such as /tmp).

1. Create a subdirectory manually under /tmp.

2. Set db_home_directory to /tmp/<subdirectory> in the file:

      <iPlanet-Home>\slapd-<instance name>\config\ slapd.ldbm.conf

   The above setting causes the internal directory server database files to be moved to the directory referenced by the parameter.

   Caution: It is possible, but unlikely, that the server will no longer start after the files have been moved, because enough memory cannot be committed. This is a symptom of an overly large database cache size being configured for the database server. If this happens, reduce the size of the database cache size to a value at which the server will start again.

   Making this setting will considerably smoothen the LDAP-write related response times. Though there will not be any considerable change in the average response times, it would reduce isolated peaks in the LDAP-write timers, thus reducing the chances of a few users being timed out.

Distributing the Write Load Among Multiple Disks

Heavy LDAP write loads can occur if there is heavy registration activity. Placing the LDAP database on a single disk can cause long write queues (serial access). Under heavy write loads, this can result in long response times. A multiple-disk system facilitates fast and simultaneous (parallel) access to the database and will reduce the write queues. In "Configuring Disks", you will find the guidelines to configure multiple disks or disk arrays. After configuring the multiple-disk system, you can distribute the LDAP database files, index files, and transaction logs across disks to achieve better response times for the registration activity.

The default installation of the directory places all directory data files under a single subdirectory. These files include:

• Database and index files

• Transaction logs used mainly for recovery purposes

• LDAP access, error, and audit logs

To store the database and log files on different disk volumes, set the directives in the data files slapd.conf and slapd.ldbm.conf to different disks.

1. Modify the directory setting in the <iPlanet-Home>/slapd-<serverID>/config/slapd.ldbm.conf file to point to a different location from its default setting of <iPlanet-Home>/slapd-<serverID>/db.

2. The default setting for the transaction log files is: <iPlanet-Home>/slapd-<serverID>/db

   Modify the db_logdirectory setting in the <iPlanet-Home>/slapd-<server ID>/config /slapd.conf file to point to a different location on a different disk from the one on which the database and index files are located.

3. In the <iPlanet-Home>/slapd-<serverID>/config /slapd.conf file, modify the accesslog setting to point to a different location on a file system mounted on a disk different from that on which the database, index, and transaction log files are set up.

4. When the installation achieves some stability, consider turning off LDAP access logs, because LDAP is very heavy in the writes to the access logs.

   In the <iPlanet-Home>/slapd-<serverID>/config /slapd.conf file, turn off access logging by setting the accesslog-logging-enabled parameter to Off.

Disabling Durable Transactions

To reduce the response time for the registration activity and also to reduce the write intensiveness on the disk to which the LDAP transaction logs are mapped, set db_durable_transactions to Off in the <iPlanet-Home>/ slapd-<serverID>/config/slapd.ldbm.conf file. This setting is expected to provide some performance gains in terms of better response times under conditions of high load of the registration activity on the site.

Quoting the Administrator's Guide for iPlanet Directory Server:

"By default, durable database transaction logging is enabled. This means that every time a write is performed on the directory, a corresponding entry is physically written to the database transaction log disk. To improve performance, you can disable durable transaction logging. When you do so, every directory database operation is logically written to the database transaction log file, but it may not be physically written to disk immediately. That means that if a directory change was written to the logical database transaction log file but not physically written to disk at the time of a system crash, you cannot recover the change. When durable transactions are disabled, the recovered database is consistent, but does not reflect the results of any LDAP write operations that completed just before the system crash."

Setting the ALL_IDS_THRESHOLD

If the community size (number of companies) exceeds the value set for ALL_IDS_THRESHOLD, a search with a filter such as ou=immOrg turns into an unindexed search, causing the search times on some community pages to be inordinately long. The default value for this setting is 4000. If the community size grows beyond 4000, considerable deterioration in performance can be expected in terms of response time for login.

The solution to this is to set the ALL_IDS_THRESHOLD to a value equal to the community size that is expected to be reached at steady state for the site.

Refer to the iPlanet Directory Server Administrator's Guide for more details on setting the appropriate value for ALL_IDS_THRESHOLD.

1. Set the ALL_IDS_THRESHOLD to the required value in the <iPlanet-Home>/slapd-<serverID>/config/slapd.ldbm.conf file.

2. Refer to the following for more information about tuning the LDAP and make the appropriate changes in settings to improve write performance on LDAP:
   • Adminstrators reference at: http://docs.iplanet.com/docs/manuals/directory/41/admin/

   • LDAP Performance Tuning Primer at: http://mc.red.iplanet.com/launches/directory/dir4launch/performance/PerfTuningPrimer.html

LDAP Indexes

While importing LDAP schema and data during the installation of iPlanet Market Maker software, LDAP indexes are created. The slapd.ldbm.conf file holds the list of indexes that are created on the LDAP database. While logging in or while performing any such task involving the LDAP database, indexed searches will be made if the indexes are present. Absence of any index will make it an unindexed search, which are very slow. The Login page and also some other pages where calls to LDAP are made for authenticating/selecting available privileges for a user will become much slower if the search is unindexed.

If the indexes on any of the following attributes are missing, notes=U entries will appear in the LDAP access logs corresponding to LDAP searches where the search filter includes any of the unidexed attributes.

The indexes listed in Table 4-1 are created. You can verify whether they are present in the slapd.ldbm.conf file.

Table 4-1    LDAP Indexes 

Index Name
index aci pres
index changenumber eq
index cn pres,eq,sub
index copiedfrom pres
index displayName sub
index dncomp eq
index entrydn eq
index givenName pres,eq,sub
index immBusinessRole eq
index immMembershipStatus eq
index immroletype eq
index iplanetecguid eq
index iplanetecparentorgguid eq
index mail pres,eq,sub
index mailAlternateAddress eq
index mailHost eq
index member eq
index memberof eq
index nsActionName eq
index nsAllowedPrincipal eq
index nsCalXItemId pres,eq,sub
index nsLIProfileName eq
index nsResourceName eq
index nswcalCALID pres,eq
index ntGroupDomainId pres,eq,sub
index ntUserDomainId pres,eq,sub
index numsubordinates pres
index o eq,sub
index objectclass eq
index ou eq
index owner eq
index parentid eq
index pipstatus eq
index pipuid pres,eq,sub
index seeAlso eq
index sn pres,eq,sub
index telephoneNumber pres,eq,sub
index uid pres,eq,sub
index uniquemember eq
pres—presence; eq—equality and sub—substring index

To add an index on an attribute in LDAP when LDAP already has data loaded, you can either use the Directory Server Console or make suitable manual additions to the slapd.ldbm.conf file.

Adding indexes through the Directory Server Console is the suggested method because addition of indexes through the console ensures that the result takes effect on the existing LDAP database retrospectively. Note that while adding indexes from the console, the server is placed in a read only mode. During this process, we can neither make any configuration changes to the server nor modify the contents of the directory.

The other method of making manual edits to the file slapd.ldbm.conf file is as follows:

1. Add these attributes manually to slapd.ldbm.conf file.

2. Create indexes on these attributes for the existing data in LDAP if it has any entries that are unindexed with respect to these attributes. This can be done by one of the two methods given below:
   • Export the database as LDIF and import it again. This will cause the indexes to be updated and applied on all the new additions in the file slapd.ldbm.conf.

     OR

   • Run the db2index command line tool.

   • Stop the server, or place LDAP in read-only mode as follows:
     1. On the Directory Server Console, select the Configuration tab.

     2. Select the Database icon in the navigation tree in the left panel.

     3. Select the Settings tab in the right panel.

     4. Select the Make Database Read-Only check box.

     5. Click Save.

   • Change the directory to <iPlanet-Home>/bin/slapd/server, where iPlanet-Home is the directory where you installed the directory server.

     In this directory, you can find a utility called ns-slapd.

   • Run the ns-slapd process as follows:

     ns-slapd db2index -f <slapd.conf> -t
     attributeName[:indexTypes]

     Where:

     • attributeName is the name of the attribute to be indexed

     • indexTypes is a comma-separated list of indexes to be created for the attribute

     • slapd.conf is the full path to the slapd.conffile

   • Restart iPlanet Directory Server.
     • If iPlanet Directory Server was running at the time of index creation, stop the server, take it out of read-only mode, and restart it.

     • If it was stopped for index creation, simply restart it.

VLV Indexing

The Virtual List View (VLV) is used to implement pagination. The iPlanet Market Maker application uses VLV control to request subsets of search results, so they can be sorted and displayed by the pages. VLV indexing allows efficient browsing of millions of entries on the search filters that are indexed. To allow efficient browsing of millions of entries, you should create a special VLV index for the query.

The VLV indexes are available only for searching and sorting (ascending/ descending) the companies on the status filters Pending, Active, and All.

The VLV index is created initially by the Installer after schema creation. A VLV index creation script (vlvindexes.bash) is placed in the $IMM_HOME/infrastructure/ldap/schema directory. For more information on VLV indexes and its usage in iPlanet Market Maker.

For more information, refer to vlvindex.README in the $IMM_HOME/infrastructure/ldap/schema directory.

Tuning Oracle

---

Distributing the Tablespaces Among Multiple-Disks

The iPlanet Market Maker software is configured to work with separate Oracle data and index tablespaces for each module, such that the tablespaces can be distributed among separate disks or disk arrays. In "Configuring Disks", you can find instructions for configuring a multiple-disk subsystem. After configuring multiple disks or disk arrays, the data and index tablespaces can be distributed across multiple disks or disk stripes. Some recommendations based on the tests carried out in our performance labs:

• Place data tablespaces and index tablespaces on separate disks or a disk stripe.

• Separate heavily used tablespaces, such as catalog, auction, and common (cmn), so that the tables can be accessed simultaneously.

• Place redo logs on a disk separate from other disks.

• Create rollback segments based on the concurrent transactions and separate rollback tablespaces.

• Place temporary tablespaces on disks separate from other tablespaces.

• Place system tablespaces on disks separate from other tablespaces.

After the installation, the Oracle data files can be moved to different locations to balance I/O.

Assume that an open database has a tablespace named USERS that is made up of data files located on the same disk of a computer. To relocate the data files of the USERS tablespace to a different disk drive, run the following steps:

1. Find the data files that need to be relocated.

   The following query of the data dictionary view DBA_DATA_FILES lists the data file names and sizes (in bytes) of the USERS tablespace:

   SELECT file_name, bytes FROM sys.dba_data_files WHERE

   tablespace_name = 'USERS';

This will return:

FILE_NAME                                  BYTES

------------------------------------------

/U02/ORACLE/RBDB1/USERS01.DBF                                  102400000

/U02/ORACLE/RBDB1/USERS02.DBF                                  102400000

2. Back up the database. Before making any structural change to a database, such as renaming and relocating the data files, it is always recommended that the entire database is backed up.

3. Take the tablespace containing the data files offline, or shut down the database and restart and mount it, leaving it closed. Both the options close the data files.

4. Copy the data files to their new locations and rename them using operating system commands. You can also run an operating system command to copy a file by using the HOST command.

5. Rename the data files within Oracle.

   The data file pointers for the files that make up the USERS tablespace, recorded in the control file of the associated database must be changed from the old names to the new names.

   1. If the tablespace is offline but the database is open, use the ALTER TABLESPACE...RENAME DATAFILE statement.

   2. If the database is mounted but closed, use the ALTER DATABASE...RENAME FILE statement.

      ALTER TABLESPACE users

      RENAME DATAFILE '/u02/oracle/rbdb1/users01.dbf',

      '/u02/oracle/rbdb1/users02.dbf'

      TO '/u03/oracle/rbdb1/users01.dbf',

      '/u04/oracle/rbdb1/users02.dbf';

6. Bring the tablespace online, or shut down and restart the database.
   1. If the USERS tablespace is offline and the database is open, bring the tablespace back online.

   2. If the database is mounted but closed, open the database.

7. Back up the database. After making any structural changes to a database, always perform an immediate and complete backup.

Refer to the Oracle 8.1.7 / 9i Administrator's Guide.

Tuning the iPlanet Application Server

---

The installations of the iPlanet Application Server should be tuned to achieve optimal performance. This section describes the settings specific to the iPlanet Market Maker application.

1. Apply the JDK1.3.3 patch provided by JavaSoft for performance improvement with the -sever option. Otherwise, response times will be unsatisfactory.

2. Set JAVA_ARGS in IAS_HOME/ias/env/iasenv.ksh to the following:

   JAVA_ARGS="-server -Xms256m -Xmx608m -XX:NewSize=96m -XX:MaxNewSize=96m -XX:SurvivorRatio=2 -XX:+UseLWPSynchronization"

3. Make a file in IAS_HOME/ias as .hotspot_compiler.

   Add the following two entries in the .hotspot_compiler file:

   exclude oracle/sql/NUMBER _isPositive
   exclude com/iplanet/ecommerce/vortex/community/UxUtilImpl populateDAG

   exclude com/iplanet/ecommerce/vortex/arch/PersistentLocalizedMessage create

4. Do not change the values for the minimum and maximum threads for the kjs processes thru the admin tool.

   Use the defaults: Minimum threads=8 and Maximum threads = 64.

   Also leave the Request Queue Low Water Mark and Request Queue High Water Mark to default values.

Creating New KJS Processes and Tuning

On a multi CPU machine, you can set side one CPU for every 4 CPUs for processes other than KJS such as ns-httpd, ns-slapd and other system monitoring tools. So, it is recommended that for every 4 CPUs, you should create three KJS processes.

1. Log in as the user for the catalog module.

2. Change directory to:

   <iAS_HOME>/ias.0sp2/ias/bin

3. Run ksvradmin.

4. Select the General tab in the iPlanet Application Server Administration Tool.

5. Select the iPlanet Application Server instance and create a new KJS process as shown in the picture below.

   
   
   

Session Model

We recommend the following iPlanet Application Server session data storage model for the optimal performance of iPlanet Market Maker.

<impl>=lite <dsync-type>=ignored <sticky>=true

Source of Session Data = KJS

Advantages

• Fast access—Session data is sourced in process with request.

• Fast access, and no restrictions on types of objects that can be store in the session—No serialization/deserialization.

Disadvantages

• No load balancing—Session data is only accessible from original KJS.

• No failover—Session data is lost if KJS crashes.

• No backward compatibility—J2EE components only; AppLogics are not supported.

The iPlanet Market Maker Installer places two XML descriptor files, ias-web.xml and web.xml, under APPS\imm40\imm40\WEB-INF.

<session-info>

<impl>lite</impl>

</session-info>

The Installer sets the <impl>lite</impl> and <sticky>true</sticky> in the ias-web.xml file, and sets the <distributable>false</distributable> in the web.xml. file.

To ensure that it is registered in the registry, you should launch the kregedit and change the default value for distributable to false as follows:

SOFTWARE/iPlanet/Application Server/6.0/J2EE-Module/imm4.0/ distributable=false

These settings along with the iPlanet Market Maker classes are registered in iPlanet Application Server registry data file, reg.dat, by invoking the iasdeploy command.

Load Balancing

Load balancing is session based. Session data is stored in the KJS. The first request in a session is load balanced. All subsequent requests in that session are sent to the server chosen for the first session request. To enable sticky load balancing for JSPs, including imm.jsp, complete the following steps. Click the Application icon in the Administration Tool to view and configure application settings.

1. Select the iPlanet Application Server instance where iPlanet Market Maker is installed as an application; navigate to the system module under Default application.

2. On the right pane, the servlets are displayed. Ensure that the Sticky Load Balance check boxes for servlets System_JSPRunner, and System_JSPRunnerSticky are checked.

3. Similarly, select the module imm40 under application imm40 and ensure that the Sticky Load Balance checkbox is checked.

4. Click Apply Changes.

5. Restart the iPlanet WebServer.

.

To Use round robin load balancing:

1. Select the tab Load Bal.... in the iPlanet Application Server Administration Tool.

2. Select an iPlanet Application Server instance and select the Round Robin (connector-driven) option for load balancing from the drop-down menu.

3. Repeat the above step for each instance of iPlanet Application Server.

4. Click Apply Changes.

5. Restart the Application Server.

Alternatively, you can perform the above settings by editing the registry as follows:

6. Run kregedit.

7. Add/modify the values for load balancing as follows:

   SOFTWARE/iPlanet/Application Server/6.0/CCS0/LOADB/Disable=0 (Integer)

   SOFTWARE/iPlanet/Application Server/6.0/CCS0/LOADB/RoundRobin=1(Integer)

   SOFTWARE/iPlanet/Application Server/6.0/CCS0/LOADB/ServerWeights/iAS1.domain.com(or IP Address 1)=1(Integer)

   SOFTWARE/iPlanet/Application Server/6.0/CCS0/LOADB/ServerWeights/iAS2.domain.com(or IP Address 2)=1(Integer)

   SOFTWARE/iPlanet/Application Server/6.0/CCS0/LOADB/ServerWeights/iAS3.domain.com(or IP Address 3)=1(Integer)

8. Restart the iPlanet Application Server.
   

   ---

   Note	To apply changes, whenever you restart iPlanet Application Server, use the iascontrol kill and iascontrol start commands instead of the iascontrol stop and iascontrol start commands.

   ---

   
   

Setting the Heap Size for JVM

It is recommended that you set the minimum and maximum Java heap size in the KJS script as 256MB and 608MB respectively. Modify the KJS script for the JAVA heap size and garbage collection parameters as follows:

JAVA_ARGS="-server -Xms256m -Xmx608m -XX:NewSize=96m -XX:MaxNewSize=96m -XX:SurvivorRatio=2 -XX:+UseLWPSynchronization"

It is not recommended to set this value lower than 256MB. You can set this to as high a value as necessary depending on the available RAM.

Tuning iPlanet Market Maker

---

Turning Off the Pricing Engine

For multiple users, the pricing engine has a significant impact on performance. If you are not actively using the pricing engine, it can safely be turned off by editing the following file:

<appserver_dir>/ias/APPS/imm40/imm40/WEB-INF/classes/CatalogConfiguration.properties

1. Set the CFG_NO_ADJUSTED_PRICES flag to true (8=true).

2. Restart the iPlanet Application Server.

Monitoring Performance

---

Monitoring performance is helpful in sizing and performance tuning. A well- tuned system should indicate:

• An even usage of CPU time across all of the servers

• An even usage of CPU time across all processors in each server

• A fairly low percentage of system time (0 - 25%), especially if the workflow is intensively computational

If you find requests waiting while the processors are not 100% busy, it indicates that the server is not tuned optimally. Check the active database connections to find the appropriate number of connections for the database connection pooling.

Monitoring Tools

A number of command-line tools are available to monitor various performance parameters on Solaris.

Monitoring I/O Usage

Run the following command to get I/O statistics:

/usr/bin/iostat

Monitoring CPU Utilization

Run the following command to get virtual memory statistics regarding process, virtual memory, disk, trap, and CPU activity:

vmstat

Monitoring Process Resource Utilization

Run the following command to get process statistics:

prstat

---

Note	Available only on Solaris 8. You can use Top as an alternate to prstat.

---

Monitoring Multi-Processor CPU Usage

Run the following command to get statistics on each processor:

/usr/bin/mpstat

Observing Memory Usage

Run the following command to get a report on process status:

# ps -Pefly | grep "\.k"

This gives a long full listing about every process with the processor number and memory utilization.

Monitoring Network Activity

To watch network activity between IP nodes (server1 and server2), run the following command:

# snoop from <server1> to <server2>

Log Files

Logging can be very useful in troubleshooting and solving problems. The web server logs will give you a good idea of activities taking place at a lower level, (for example, JVM issues). The iPlanet Market Maker logs will give you a great deal of application-specific messages, which will be invaluable as you debug a problem. Fresh logs are created every time the iPlanet WebServer JVM restarts.

While debugging a problem, it is a good idea to tail the output of the iPlanet Market Maker log file to watch for errors as JSP pages are returned.

You can adjust the debug settings for the iPlanet Market Maker installation to get a more detailed internal view of the application.

iPlanet Market Maker Logs

The iPlanet Market Maker logs are located under the iMM/logs directory. You can set the debug level in the file VortexConfiguration.properties file.

#CFG_DEBUG_LEVEL (off=3, terse=7, verbose=15, vverbose=31)
# - Debug level for the Market Maker system.
5=3

The default setting of OFF means that only errors will be logged. It is recommended not to increase the debug level to any point above terse, because the log volume will quickly be overwhelming. Be sure to set debug to OFF when running under a load, as it will have a dramatic negative impact on performance if debug remains ON.

Every time you recycle the iPlanet WebServer, it creates a new log file with a time stamp. The location of the debug log files is specified in the file VortexConfiguration.properties file as follows:

#CFG_DEBUG_DESTINATION
# - Location of the debug log file.
6=@IMM_HOME@/logs/imm.log

iPlanet Application Server Logs

Log files can help you monitor server activity and troubleshoot problems.

To configure logging options for iPlanet Application Server:

1. Access the administration tool and choose the Logging tab.

   Here, you can choose to log Errors only, Errors and Warnings, or All Messages. You can choose to log the messages to a database, console, or a file. For better performance, it is recommended that you disable logging.

2. Deselect the Enable Server Event Log option to ensure best performance. With this setting, the exceptions from applications will still be reported in KJS logs.

To view the error log file:

• To view application logs, open KJS logs from the <iAS-HOME>/logs directory, and open iPlanet Market Maker logs from the <iMM-HOME>/logs directory.

• To troubleshoot iPlanet Application Server problems, open kxs.log, kas.log and ias.log files from the <iAS-HOME>/logs directory.

For more details on logging options, refer to the iPlanet Application Server Administrator's Guide.

iPlanet Directory Server Logs (LDAP)

Access, audit, and error logs are generated by LDAP. A number of settings related to logging can be made in the <iPlanet-Home>/slapd-<server ID>/config /slapd.conf file. When the installation achieves some stability, turn off access logging by setting accesslog-logging-enabled to Off.