5.2 Tuning the Access Gateway for Performance

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

5.2.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: NetIQ recommends that you keep the maximum number of user sessions per Access Gateway to 48,000. If your Access Gateways are exceeding this number or getting close to it, you can add another Access Gateway to the cluster.

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

LDAP Attributes: If you have policies that use LDAP attributes, configure the embedded service provider (ESP) 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 NetIQ Access Manager 4.0 SP1 Identity Server Guide.

Web Servers: Web servers or services can be a major cause of slowness because they process the most information. You need to examine the content on the Web servers. If users are requesting static pages with multiple images, you need to improve the performance by having the Access Gateway cache these pages. For information about cache configuration options, see Configuring Caching Options in the NetIQ Access Manager 4.0 SP1 Access Gateway Guide.

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

L4 Switch: 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 NetIQ Access Manager 4.0 SP1 Setup Guide.

Policies: You need to implement the Authorization, Identity Injection, and Form Fill policies 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 troubleshoot a problem. As soon as the problem is resolved, you should reduce the log level. You should also have a schedule to check the number and size of the log files and to remove 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 access, 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 Configuring Logging for a Proxy Servicein the NetIQ Access Manager 4.0 SP1 Access Gateway Guide.

Access Gateway Service: See Section 5.2.5, Performance Tips.

5.2.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 5-2 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 5-2 Two-Member Access Gateway Cluster

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

Gather the required information. For each Access Gateway in the cluster, you need 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.
Log in to the Access Gateway as the root user.
Change to the WEB-INF directory:

Linux: /opt/novell/nam/mag/webapps/nesp/WEB-INF/

Windows: \Program Files\Novell\Tomcat\webapps\agm\WEB-INF/
Open the web.xml file for editing.
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 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 configure. 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 5-2, 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 5-2 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>
```
Save the file.
Restart Tomcat:

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

Windows: Enter the following commands:
```
net stop "Apache Tomcat"
net start "Apache Tomcat" 
```
Repeat Step 2 through Step 7 for each cluster member, modify the <param-value> element to contain the addresses for other members of the cluster.

5.2.3 Configuring the Access Gateway ESP to Reduce the Access Gateway Load and Improve Performance

Identify all policies that are enabled for each defined protected resource.
Go through each of these policies and note the attributes that are required by this policy.

For example, you might find that single policy is enabled for one protected resource and the policy requires the following attributes: all user roles, LDAP cn, LDAP roomNumber, LDAP mail, and LDAP title.
Define an attribute set that contains all attributes required by the Access Gateway enabled policies.

For more information about how to configure a new attribute set, see Configuring Attribute Sets in the NetIQ Access Manager 4.0 SP1 Identity Server Guide.

NOTE:The local attribute must include the attribute that the Identity Server evaluates. Ignore the Remote Attribute option for communications between the Identity Server and embedded service provider (ESP).
In the Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty, then select the Access Gateway or Access Gateway cluster configuration for which you want to use the newly defined attribute set.
Add the newly defined attribute set to the Liberty relationship between the Identity Server and the selected ESP.

For more information about how to add the attribute set, see Configuring the Attributes Sent with Authentication in the NetIQ Access Manager 4.0 SP1 Identity Server Guide.
Define the attribute refresh rate for the policy.

The LDAP attribute for an Identity Injection or Form Fill policy can be configured to refresh its value according to a specified interval.

For more information, seeUsing the Refresh Data Option in the NetIQ Access Manager 4.0 SP1 Policy Guide.

This refresh rate determines how often the Access Gateway proxy must go back to the ESP to determine whether the data is valid. For performance purposes, you should define the Session setting for retrieving the attributes only one time during the session. This reduces the communication between the Access Gateway proxy and the ESP.
Inject the Identity Server user name and password to the back-end Web server.

If the policy requires the credential profile user name and password to be sent to the back-end Web server, the attribute map must include the credential profile details. Unlike regular LDAP attributes, these credential profile attributes must be mapped to a Remote Attribute name.

The Remote Attribute name is case-sensitive.

You need to map the UserName, userPassword, and userDN credential profile attributes. When you define the attributes to send to the back-end Liberty ESP, you need to send the UserName and userPassword. The userDN can be left in the available list because it was already sent in a SAML assertion by default at authentication time.

5.2.4 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 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.

Log in to the Access Gateway as the root user.
Open the Tomcat configuration file for editing.
```
/opt/novell/nam/mag/conf/tomcat7.conf
```
For the Access Gateway Service, find the following line in the file:
```
JAVA_OPTS="-server -Xmx2048m -Xms512m -Xss128k
```
This -Xmx value is ideal for a system with 4 GB of memory. If the system has more physical memory, increase the -Xmx value. For example, if the system has 8 GB of memory, increase -Xmx to 4096.

Find the following line in the file:

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

If required change the -Dnids.freemem.threshold value to a value between 5 and 15. The default value is 10.

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.
Save your changes, then restart Tomcat.
Repeat these steps for each Access Gateway in your cluster.

Modifying Java Parameters on Windows

Open the Tomcat configuration utility.

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

Click the Java tab.
In the Java options section, find the following line:
```
-Dnids.freemem.threshold=10 
```
If the line does not exist, you need to add it.
If required change the -Dnids.freemem.threshold value to a value between 5 and 15. The default value is 10.

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.
Change the Maximum memory pool size to 2048.

This allows Java to use 2 GB of memory.
Save your changes, then restart Tomcat.
Repeat these steps for each Access Gateway in your cluster.

5.2.5 Performance Tips

Caching: Use a high performance disk system for the cache directory, such as tempfs on Linux.

You can improve the speed of adding files to cache and retrieving them from cache if you turn off gathering cache statistics. Click Devices > Access Gateways > Edit > Advanced Options and add the following command:

DiskCacheMonitorStats off

SSL Terminator: Install an SSL terminator between the browsers and the Access Gateway. This reduces the amount of rewriting required when the browsers are using SSL and the Web servers protected by the Access Gateway are not configured for SSL.

Click Devices > Access Gateways > Edit > Reverse Proxy / Authentication. Enable the Behind Third Party SSL Terminator option.

SSL Cipher Suites: Use the advanced options from Apache to set the cipher suites that you want to allow. Some cipher suites take longer than others to process.

For more information, see “SSLCipherSuite Directive”.

Statistics: If additional performance is desired and statistics are not important, you can unload the mod_status module. If you unload the mod_status module, extended information is not gathered.

To unload the module, open the httpd.conf file in the apache directory, and add a comment symbol (#) to the line that loads the mod_status module in the Load Module section.

If you turn on debug mode, the mod_status module is automatically loaded in order to gather as much information as possible.

5.2.6 Setting Cache Store Size in Access Gateway Appliance

To set the disk space of cache, in megabytes, use the DiskCacheMonitorCacheStoreSize parameter in the /etc/opt/novell/ag/mod_disk_cache_monitor.conf configuration file.

This parameter is by default set to 1024 megabytes.