4.10 Tuning the Access Gateway for Performance

Use the following information to improve the performance of your Access Gateway cluster.

4.10.1 Basic Tuning Options

The following Access Manager components and features can affect the performance of the Access Gateway cluster.

Maximum Number of User Sessions: Currently, we recommend that you keep the maximum number of user sessions per Access Gateway to 5000 sessions. If your Access Gateways are exceeding this number or getting close to it, we recommend that you add another Access Gateway to the cluster.

If you want to support more than 5000 sessions per Access Gateway, you need to modify the Java memory parameters. For configuration information, see Section 4.10.3, Java Memory Allocations:.

LDAP Attributes: If you have policies that use LDAP attributes, configure the Embedded Service Provider to obtain these attribute values at authentication. When a policy needs to be evaluated for a user, the values are then available in cache. If the values are not in cache, an LDAP query must be sent to retrieve them. If the user then accesses another resource that requires different LDAP attributes, another query must be sent. For configuration information, see Sending Attributes to the Embedded Service Provider in the Novell Access Manager 3.1 SP2 Identity Server Guide.

Identity Server Configuration: A number of the configuration options for the Identity Server add authentication overhead. You need to balance possible performance enhancements with your needs to enable these options. For example, limiting user sessions adds another check to the authentication process. If your security model does not require limiting user sessions, you should not enable this feature. For other configuration options that affect the performance of the Identity Server, see Tuning the Identity Server for Performance in the Novell Access Manager 3.1 SP2 Identity Server Guide.

Web Servers: Web servers or services can be a major cause of slowness because they are processing the most information. You need to examine the content on the Web servers. If users are requesting static pages with multiple images, performance should be improved by having the Access Gateway cache these pages. For information on cache configuration options, see Section 5.1, Configuring Caching Options.

If your Web servers are serving dynamic content, you can upgrade your Web servers to faster hardware, or you can add another server to the group of Web servers serving the dynamic content.

L4 Switches: If the switch is slow or misconfigured, it can severely impact performance. You need to make sure the switch has ample capacity to handle the traffic. If possible, clustered Access Gateways should be plugged directly into the switch or segmented accordingly. It is also critical that you enable sticky bit/persistence on the L4 switch. When this feature is not enabled, the product handles the traffic correctly, but the system can run up to 50% slower than when persistence is enabled. For tips on how to set up the L4 switch, see Configuration Tips for the L4 Switch in the Novell Access Manager 3.1 SP2 Setup Guide.

Policies: Authorization, Identity Injection, and Form Fill policies need to be implemented so that they execute as quickly as possible. For example, a Form Fill policy impacts performance when the form matching criteria are set up so that an entire directory of files must be searched before the form is found. Also when policies are assigned to a protected resource, one policy with ten actions executes faster than ten policies with one action in each policy.

Logging: You need to manage the size and number of log files as well as the logging level. You should increase the log level to Debug only when you are troubleshooting a problem. As soon as the problem is resolved, you should reduce the log level. You should also have a schedule for checking the number and size of the log files and for removing the older log files.

Auditing: You need to carefully select the events that you audit. Selecting all events that are available for the Access Manager components can impact performance. For example, the URL Accessed event of the Access Gateway generates an event every time a user accesses a resource. If you have many users and many resources that these users are accessing, selecting this event could impact performance. You need to analyze your needs to see if you need to audit all URLs accessed. If you need to audit only a few URLs, you can use proxy service logging to gather the information. See Section 4.3, Configuring Logging for a Proxy Service.

Access Gateway Service: For some tuning options that apply only to the Access Gateway Service, see Section 8.6, A Few Performance Tips.

4.10.2 Configuring a Specific IP Address for Proxied Requests

The default behavior for the Access Gateway is to use the same IP address for incoming client requests, for proxied requests, and for management tasks. You can improve performance by separating this traffic into separate pools via IP addresses. You can also use the IP addresses to route the traffic so that it remains behind the firewall.

In version 3.1 SP2 IR1 and later, you can specify the IP address that an Access Gateway uses for proxied requests to other members of the cluster. A proxied request is sent to another member of a cluster when the request is not sent to the authoritative server.

An authoritative server is the cluster member that holds the authentication information for a given user session. For a request associated with a given session to be processed, it must be routed or proxied to the authoritative cluster member. If an L4 switch sends a request to a non-authoritative cluster member, that cluster member proxies that request to the authoritative cluster member.

You can also specify the IP address for the communication that takes place between the Access Gateway and the Administration Console for management tasks. This includes configuration updates, health checks, and statistics. To modify this IP address, log in to the Administration Console, then click Devices > Access Gateways > [Name of Access Gateway].

Figure 4-1 illustrates a configuration with a two-member cluster. The L4 switch sends client traffic to the Access Gateways by using the IP addresses that start with 192. The IP addresses that start with 10 are used to route proxied requests to the cluster members. The IP addresses starting with 151 are used for the management traffic with the Administration Console.

Figure 4-1 Two-Member Access Gateway Cluster

To specify the IP address for the proxied requests on the SOAP channel:

  1. Gather the required information. For each Access Gateway in the cluster, you need to know the following information:

    • IP address of the authenticating reverse proxy. (To get this value, click Devices > Access Gateways > Edit. Select the reverse proxy that is used for authentication. Use the Cluster Member drop-down list to display the IP address for the various cluster members.)

    • Management IP address. (To get this value or modify the value, click Devices > Access Gateways > [Name of Access Gateway].)

    • IP address or IP address with port that is available to use for proxied requests.

  2. Log in to the Access Gateway as the root user.

  3. Change to the WEB-INF directory:

    Linux: /var/opt/novell/tomcat5/webapps/nesp/WEB-INF/

    Windows: \Program Files\Novell\Tomcat\webapps\agm\WEB-INF/

  4. Open the web.xml file for editing.

  5. Add a proxyAddessMap parameter entry to the file.

    <context-param>
    <param-name>proxyAddressMap</param-name>
    <param-value>Managament_IP, Reverse_Proxy_IP, Proxied_Request_IP
        </param-value>
</context-param>

    The <param-value> element specifies the IP addresses that are used by the other members of the cluster. It is a comma-separated list of IP addresses. You need a value entry for each member of the cluster, except the cluster member you are configuring. A member does not send proxied requests to itself, so you do not need to add it. Each value entry must contain three IP addresses:

    • Replace Management_IP with the management IP address of the Access Gateway. You cannot specify a port with this entry.

    • Replace Reverse_Proxy_IP with the IP address of the reverse proxy of the Access Gateway. You cannot specify a port with this entry.

    • Replace Proxied_Request_IP with the address to use for the proxied requests (also called the SOAP back channel). You can specify a port with this entry, such as 151.155.152.30:445.

    For Access Gateway 1 in Figure 4-1, the entry should look similar to the following lines:

     <context-param>
    <param-name>proxyAddressMap</param-name>
    <param-value>151.155.152.40,192.155.153.25,10.1.10.22</param-value>
 </context-param>

    If your cluster has three or more members, you need to add addresses for the other members. The following example shows an entry for Access Gateway 1 in Figure 4-1 if the cluster contained a third member.

     <context-param>
    <param-name>proxyAddressMap</param-name>
    <param-value>151.155.152.40,192.155.153.25,10.1.10.22,
        151.155.152.50,192.155.153.35,10.1.10.23</param-value>
 </context-param>

  6. Save the file.

  7. Restart Tomcat:

    Linux: /etc/init.d/novell-tomcat5 restart

    Windows: Enter the following commands:

    net stop "Apache Tomcat"
net start "Apache Tomcat"

  8. Repeat Step 2 through Step 7 for each cluster member, modifying the <param-value> element to contain the addresses for the other members of the cluster.

4.10.3 Java Memory Allocations:

The Tomcat configuration file controls the amount of memory that Tomcat can allocate for Java. If you have installed your Access Gateway on a machine with the recommended 4 GB of memory, you can modify two parameters in this file to improve performance under heavy load:

Modifying the Java Parameters on Linux

On the Access Gateway Appliance, you need to modify just the free memory threshold for best performance. On the Access Gateway Service, you need to modify the free memory threshold and the amount of memory that Java can use.

  1. Log in to the Access Gateway as the root user.

  2. Open the Tomcat configuration file for editing.

    /var/opt/novell/tomcat5/conf/tomcat5.conf

  3. For an Access Gateway Service, find the following line in the file:

    JAVA_OPTS="-server -Xmx1024m -Xms512m -Xss128k -XX:+UseConcMarkSweepGC"

  4. Replace the -Xmx value (default is 1024) with 2048.

    This allows Java on the Access Gateway Service to use 2 GB of memory. For the Access Gateway Appliance, the default value works best so do not change the value.

  5. Find the following line in the file:

    JAVA_OPTS="${JAVA_OPTS} -Dnids.freemem.threshold=0"

  6. Change the -Dnids.freemem.threshold value from 0 to a value between 5 and 15.

    This prevents user sessions from using up all the memory and ensures that there is free memory available so that the other internal Java processes can continue to function. When this threshold is reached, the user receives a 503 server busy message and a threshold error message is logged to the catalina.out file.

  7. Save your changes, then restart Tomcat.

  8. Copy the modified file to each Access Gateway in the cluster, then restart Tomcat on each machine.

Modifying the Java Parameters on Windows

  1. Log in to the Access Gateway as the administrator.

  2. Open the Tomcat configuration utility.

    /Program Files/Novell/Tomcat/bin/tomcat5w.exe

  3. Click the Java tab.

  4. In the Java options section, find the following line:

    -Dnids.freemem.threshold=0

    If the line does not exist, you need to add it.

  5. Change the -Dnids.freemem.threshold value from 0 to a value between 5 and 15.

    This prevents user sessions from using up all the memory and ensures that there is free memory available so that the other internal Java processes can continue to function. When this threshold is reached, the user receives a 503 server busy message and a threshold error message is logged to the stdout.log file.

  6. Change the Maximum memory pool size to 2048.

    This allows Java to use 2 GB of memory.

  7. Save your changes, then restart Tomcat.

  8. Repeat these steps for each Access Gateway in your cluster.