Performance Tuning Questions and Answers

How can I improve authentication performance against any LDAP v3 data repository?

If the Profile Ignored option is selected in the Access Manager console (go to Realm > Authentication >Advanced Properties), performance may improve. However, improved performance is not guaranteed because the Profile Ignored option prevents applications and policy agents from retrieving the user's profile attributes. The amtune script automatically tunes the LDAP connection pool for the Access Manager root realm which points to the configuration Directory Server instance. But the amtune script will not tune the subrealm you created, the subrealm where the LDAP v3 data repository is configured. You may need to manually tune the LDAP connection pool. After tuning the LDAP connection pool, if poor performance persists, troubleshoot the LDAP v3 repository itself.

Consider limiting the time you spend troubleshooting authentication performance issues. Authentication usually contributes only a small portion of the overall system overhead. Authorizations tend to be slower and a lot more frequent than other processes. But each user session involves only one authentication and multiple authorizations.

How do I set the JVM heap sizes and other JVM option tuning parameters for a Distributed Authentication UI web application?

The web container that will load the Access Manager Distributed Authentication UI web application should have the same heap sizes and the same JVM tuning settings as the web container that runs Access Manager. You can use amtune-ws7, amtune-ws61 or amtune-as8 which come with Access Manager 7.1. You don't need much CPU usage as for Access Manager server machines. It is hard to tell by what ratio one can reduce the number of CPU usage on a Distributed Authentication UI machine. The ratio can be 1:4 or less. Run some load tests for a specific scenario to determine a good ratio.

The reason why a Distributed Authentication UI web container needs the same JVM heap sizes and garbage collection tuning parameters as those for the Access Manager server web containers is that amclientsdk maintains the same number of Access Manager sessions on the client side as on the Access Manager server itself. A Request for Enhancement (CR 6465831) has been filed for removal of the Access Manager sessions in Distributed Authentication UI amclientsdk deployments.

What is the impact of checking notenforced_list for a set of URIs or URLs on J2EE policy agents?

The performance impact of checking notenforced_list is negligible. In general, having a notenforced_list of commonly requested and static content improves the overall system performance.

What is the impact of using the SSL , for example the NSS library version that comes with JES 4 installer, on the performance of Access Manager 7.0 deployed on Niagara boxes such as T1000 or T2000?

If Access Manager 7.0 was installed using JES 4 installer and its default SSL libraries, then the markedly improved performance that comes with NSS 3.11 may not be present and won't be used. Use the NSS libraries version 3.11 or higher when Access Manager 7.0 is deployed on Niagra T1000 or T2000 systems. Go to the Sunsolve web site for downloading the NSS libraries. Note that starting with JES 5 and Access Manager 7.1, the NSS libraries have been upgraded to a version higher than 3.11.

Why is it so slow to create or delete users if I use a program based on amsdk, but much faster if I use the ldapmodify command?

If the same policy is modified for each user, the XML parsing and processing must occur for every user. So you should group as many users as possible with the same one policy, and then add the users to that policy. You should use the same LDAP group or role for as many users as possible in an organization.

Be sure that a policy is not modified or updated for each user. Modifying a policy is an expensive operation since the policy is stored as XML data.

Is Sun Java Message Queue tuning necessary when session failover is configured for Access Manager?

In most deployments using Access Manager session failover, Java Message Queue tuning only requires setting adequate JVM heap and stack sizes. See the Sun Java System Message Queue 2005Q1 Administration Guide at http://docs.sun.com/app/docs/coll/MessageQueue_2005Q1 for further information.

When the amtune script tunes the Directory Server with the recommended values, an onscreen message says the tuning parameters such as minConnPool and maxConnPool in serverconfig.xml are dependent on the number of Access Manager instances and other factors. How exactly should I tune the Directory Server with these factors taken into account?

Values recommended by the amtune script for minConnPool and maxConnPool are per Access Manager server instance. The parameters are stored in /etc/opt/SUNWam/config/serverconfig.xml. The recommended values are based on the following assumptions:

• One AM server instance is in front of one Directory Server.

• The Directory Server contains both Access Manager configuration data and user data.

When multiple Access Manager instances exist, the total number of persistent LDAP connections may be too high for the Directory Server to handle. Each Access Manager instance establishes its own pool of the same size. Memory allocation is also on the high side if the user data is not stored there. The amtune script assumes the user data is stored together with Access Manager configuration data in the Directory Server.

For example, consider the typical real-world deployment scenario illustrated in the document Deployment Example 1: Access Manager 7.1 Load Balancing, Distributed Authentication UI, and Session Failover. This deployment differs from the amtune script assumptions in the following ways:

• Multiple Access Manager instances are in front of the Directory Server.

• The Directory Server instance stores only Access Manager configuration data, and does not store user data.

• A separate Directory Server stores the user data.

First, if you have a large number of Access Manager instances, you can reduce the recommended pool size for the configuration Directory Server. This only applies when you have large number of Access Manager instances. When you have only two or three Access Manager instances, it may not be necessary to reduce the pool size.

Secondly, you can significantly reduce the memory allocation to the configuration Directory Server . The configuration data is minimal with usually only a few thousands entries. Reducing the memory allocation is particularly important if the configuration Directory Server runs on the same host as the user data Directory Server. You do not want the smaller configuration Directory Server to compete with the larger user data Directory Server for the system memory.

Thirdly, be sure to tune the user data Directory Server. This directory contains a large data set. You can use the amtune recommended Directory Server tuning changes as a starting point. For more information, see step 3 of Related Systems Tuning.

Ultimately, you have to look at your directory data and tune it specifically. This is the standard Directory Server tuning procedure. See the DS Performance Tuning Guide.

Finally, the amtune script does not tune the LDAPv3 data store connection pool which is used by Access Manager to access the user data Directory Server. You have to manually tune the data store connection pool. See step 4 of Related Systems Tuning.

Where do I find specific performance tuning guidelines for Access Manager implementations on the T2000 platform?

The Access Manager amtune script does the automatic tuning specifically for the T2000 platform. No manual tuning is necessary. The following is the tuning specific to T2000, done automatically by the amtune script.

Sun Fire CoolThreads technology servers, specifically Sun Fire T1000 and Sun Fire T2000 servers, contain a single Ultrasparc T1 chip or processor. The T1 processor is a unique design of 8 individual processing units, called cores, sharing one on-chip interconnection. It is somewhat like an 8-way system on a single chip.

Each core supports 4 hardware threads of execution. These hardware threads are scheduled on the core processing unit in round-robin order. A different software thread can run on each one of these hardware threads. Thirty-two software threads can run in parallel on a single T1 processor.

You can determine the number of cores by dividing the number of hardware threads (run psrinfo -v) by 4. The T1000 and T2000 can have a maximum of 4 hardware threads per core. So the number of cores is usually 6 (a 24 thread system) or 8 (a 32-thread system).

The only JVM parameter that would be different for Chip Multi-threading (CMT) servers is the following parameter

-XX:ParallelGCThreads=N

By default, if the parameter is not set, the value of ParallelGCThreads would be the same number as the number of hardware threads (either 24 or 32) on the T1000 and 2000. This is unnecessarily high. The amtune script today automatically sets the number of these parallel GC threads to be equal the number of cores in a T1000 or T2000 box.

For more information, see the document Java Tuning Whitepaper at http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2.1 .