4.2 Tuning Access Gateway for Performance

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

4.2.1 Basic Tuning Options

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

Maximum Number of User Sessions: It is recommended 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 Java Memory Allocations.

LDAP Attributes: If policies 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 5.0 Administration 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 Access Gateway cache these pages. For information about cache configuration options, see Configuring Cache Options in the NetIQ Access Manager 5.0 Administration 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 mis-configured, 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.

See Configuration Tips for the L4 Switch in the NetIQ Access Manager 5.0 Administration 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 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 5.0 Administration Guide.

Access Gateway Service: See Section 4.2.5, Performance Tips.

4.2.2 Configuring a Specific IP Address for Proxied Requests

The default behavior for 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.

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 Access Gateway and Administration Console for management tasks. This includes configuration updates, health checks, and statistics. To modify this IP address, log in to Administration Console, then click Devices > Access Gateways > [Name of Access Gateway].

Figure 4-2 illustrates a configuration with a two-member cluster. The L4 switch sends client traffic to 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 Administration Console.

Figure 4-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.
Open Access Gateway’s web.xml.

For information about how to open and modify a file, see Modifying Configurations in the NetIQ Access Manager 5.0 Administration Guide.
Add the 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 Access Gateway. You cannot specify a port with this entry.
- Replace Reverse_Proxy_IP with the IP address of the reverse proxy of 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-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 4-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>
```

4.2.3 Configuring Access Gateway ESP to Reduce 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 Access Gateway enabled policies.

For information about how to configure a new attribute set, see Configuring Attribute Sets in the NetIQ Access Manager 5.0 Administration Guide.

NOTE:The local attribute must include the attribute that Identity Server evaluates. Ignore the Remote Attribute option for communications between Identity Server and embedded service provider (ESP).
In Administration Console, click Devices > Identity Servers > Servers > Edit > Liberty, then select 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 Identity Server and the selected ESP.

For information about how to add the attribute set, see Configuring the Attributes Sent with Authentication in the NetIQ Access Manager 5.0 Administration 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 information, seeUsing the Refresh Data Option in the NetIQ Access Manager 5.0 Administration Guide.

This refresh rate determines how often 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 Access Gateway proxy and the ESP.
Inject 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.

4.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:

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

Open Access Gateway’s tomcat.conf.

For information about how to open and modify a file, see Modifying Configurations in the NetIQ Access Manager 5.0 Administration Guide.
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"

Change the -Dnids.freemem.threshold value to a value between 5 and 15 based on your requirement. 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.

For example, the threshold value is 10. When the memory goes above 90% used, the user receives a 503 Server Busy message.

4.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 Access Gateway. This reduces the amount of rewriting required when the browsers are using SSL and the Web servers protected by 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.

For information about how to open and modify a file, see Modifying Configurations in the NetIQ Access Manager 5.0 Administration Guide.

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

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

For information about how to open and modify a file, see Modifying Configurations in the NetIQ Access Manager 5.0 Administration Guide.