Sun ONE logo PreviousContentsIndexNext
Sun ONE Portal Server 6.0 Deployment Guide

 

Chapter 8 Monitoring and Tuning Your Portal

This chapter describes how to monitor and tune Sun[tm] ONE Portal Server, including Sun[tm] ONE Portal Server, Secure Remote Access.

This chapter contains the following sections:

Monitoring Sun ONE Portal Server

This section describes the variables that affect portal performance, as well as the portal monitoring you can perform. Areas to monitor include:

  • Sun[tm] ONE Identity Server

  • Desktop

  • Sun[tm] ONE Directory Server

  • Java[tm] Virtual Machine

While there are emerging technologies that will enable you to perform detailed monitoring of Portal Server components, this section focuses on the basic but extensive set of hardware and software issues that determine the overall performance of a portal deployment.

Specifically, portal performance is determined by the throughput and latency of which it is capable over a period of time. As described in Chapter 7 "Creating Your Portal Design," you must conduct a baseline performance analysis as soon as possible. The baseline performance analysis confirms that your portal substantially conforms to published performance numbers. Establishing a performance baseline helps you to sort out infrastructure issues that can severely impact the performance of a production portal.

Nevertheless, when maintaining a properly performing portal, you must look at a broad set of issues. The following sections explain those issues in terms of portal performance variables and describes rules of thumb for determining portal efficiency.

 

Note

These rules also apply for performance, scalability, and stress tests.

Memory Consumption and Garbage Collection

Before reading this section, read the following document on tuning garbage collection with the Java Virtual Machine, version 1.3.1:

http://java.sun.com/docs/hotspot/gc/index.html

Portal Server requires substantial amounts of memory to provide the highest possible throughput. In fact, the BaseDir/SUNWps/bin/perftune tuning script sets the heap size maximum to 2 GB. This size is divided between the new generation, which receives 256 MB (one eighth of the space) and the old generation, which receives the rest. (At initialization, a maximum address space is virtually reserved but not allocated physical memory unless it is needed. The complete address space reserved for object memory can be divided into the young and old generations.)

Most applications suggest using a larger percentage of the total heap for the new generation, but in the case of Portal Server, using only one eighth the space for the young generation is appropriate, because most memory used by Portal Server is long-lived. The sooner the memory is copied to the old generation the better the garbage collection (GC) performance.

Even with a large heap size, after a portal instance has been running under moderate load for a few days, most of the heap will appear to be used because of the lazy nature of the GC. Until the resident set size (RSS) reaches approximately 85 percent of the total heap space, the GC will start performing full garbage collections. Those garbage collections can have a measurable impact on performance.

For example, on a 900 MHz UltraSPARC[tm], a full GC on a 2 GB heap can take over ten seconds. During that period of time, the system is unavailable to respond to web requests. During a reliability test, full GCs are clearly visible as spikes in the response time and it is important to understand the impact on performance and the frequency of full GCs. In production, full GCs will go unnoticed most of the time, but any monitoring scripts that measure the performance of the system need to account for the possibility that a full GC might occur.

Measuring the frequency of full GCs is sometimes the only way to determine if the system has a memory leak. It is important to conduct an analysis that shows the expected frequency (of a baseline system) and compare that to the observed rate of full GCs. To record the frequency of GCs, use the vebose:gc JVM[tm] parameter.

CPU Utilization

When deployed using the building module concept (as described in Chapter 7 "Creating Your Portal Design"), Portal Server has a capable, scalable CPU architecture that also degrades gracefully under high loads.

However, when monitoring a production site, keep track of CPU utilization over time. Load usually comes in spikes and keeping ahead of those spikes involves a careful assessment of availability capabilities.

Most organizations find that portal sites are "sticky" in nature. This means that site usage grows over time even when the size of the user community is fixed, as users become more comfortable with the site. When the size of the user community also grows over time a successful portal site can see a substantial growth in the CPU requirements over a short period of time.

When monitoring a portal server's CPU utilization, determine the average page latency during peak load and how that differs from the average latency.

Expect peak loads to be four to eight times higher than the average load, but over short periods of time.

Identity Server Cache and Sessions

The performance of a portal system is affected to a large extent by the cache hit ratio of the Identity Server cache. This cache is highly tunable, but there is a trade-off between memory used by this cache and the available memory in the rest of the heap.

You can enable the amSSO and amSDKStats logs to monitor the number of active sessions on the server and the efficiency of the Directory Server cache. These logs are located by default in the /var/opt/SUNWam/debug directory. See "To Enable Identity Server Performance Statistics"" for more information. Use the com.iplanet.am.stats.interval parameter to set the logging interval. Do not use a value less than five (5) seconds. Values of 30 to 60 seconds give good output without impacting performance.

The com.iplanet.services.stats.directory parameter specifies the log location, whether to a file or to the console, and also is used to turn off the logs. You must restart the server for changes to take effect. Logs are not created until the system detects activity.

 

Note

Multiple web server instances write logs to the same file.

The cache hit ratio displayed in the amSDKStats file gives both an internal value and an overall value since the server was started. Once a user logs in, the user's session information remains in cache indefinitely or until the cache is filled up. When the cache is full, oldest entries are removed first. If the server has not needed to remove a user's entry, it might be the case that on a subsequent login-days later, for example-the user's information will be retrieved from the cache. Much better performance occurs with high hit ratios. As a rule of thumb, a hit ration of a minimum of 80 percent is a good target although (were it possible) an even higher ratio is desired.

Thread Usage

Use the web server tools to monitor the number of threads being used to service requests. In general, the number of threads actually used is generally lower than many estimates, especially in production sites where CPU utilization usually is far less than 100 percent.

Portal Usage Information

Currently, Portal Server does not include a built-in reporting mechanism to monitor portal usage information by portal users. This includes which channels are accessed, how long they are accessed, and the ability to build a user behavioral pattern of the portal. However, it is relatively simple to build a simple Java[tm] servlet that would intercept every Portal Server Desktop request, extract the SSO token, save the user access information to a log, then redirect the user to the intended URL. Such a construct would be based on custom attribute extensions to Identity Server schema.

To Enable Identity Server Performance Statistics

  1. Edit the BaseDir/SUNWam/lib/AMConfig.properties file as follows:

    		2.
    com.iplanet.services.stats.state=file
    com.iplanet.am.stats.interval=logging_interval

    To minimize overhead, do not set logging_interval below five (5) seconds.

  2. Restart the server.

    3. Cache hits ratio statistics are available in the /var/opt/SUNWam/debug/amSDKStats file. SSO token (session) statistics are available in the /var/opt/SUNWam/debug/amSSO file. This logs the number of new sessions since the last stats interval.

     

To Enable Desktop Performance Monitoring (Optional)

  • Specify the following in the /etc/opt/SUNWps/desktop/desktopconfig.properties file:

    		•
    perfLevel=message

The performance output will be logged in the /var/opt/SUNWam/debug/desktop.perf file by default.

 

Note

Using a value greater than error for perfLevel impacts performance.

To Enable Web Server perfdump and stats-xml Output

  • Make the following additions to the BaseDir/SUNWam/servers/https-server/config/obj.conf file:

    		•
    <Object name=default>
    --- make the following two additions after the above line ---
    NameTrans fn="assign-name" name="stats-xml" from="(/stats-xml|/stats-xml/*)"
    --- then add the following lines ---
    <Object name="stats-xml"> Service fn="stats-xml" </Object>
    <Object name="perf"> Service fn="service-dump" </Object>
  • Append the following lines to the BaseDir/SUNWam/servers/https-server/config/magnus.conf file:

    		•
    Init fn=stats-init update-interval="10" virtual-servers="1" profiling="yes"
    Init fn=perf-init disable=false

To Enable Verbose Garbage Collection

  • Specify the following in the BaseDir/SUNWam/servers/https-server/config/jvm12.conf file:

    		•
    jvm.printErrors=2
    jvm.option=-verbose:gc

To Resolve Bottlenecks

Use the following tools to help resolve your portal bottleneck issues.

  • To monitor JVM memory, the number of system threads, and the CPU utilization of the httpd process, run the top utility.

  • To check all the child processes for a process, run prstat. For example:

    • prstat -L -p pid_of_web_instance

  • To get a stack trace for each lightweight process for a process, run pstack. For example:

    • pstack pid_of_web_instance

  • To report on virtual memory statistics regarding process, virtual memory, disk, trap, and CPU activity, use vmstat.

  • To report on per-processor statistics, use mpstat.

  • To monitor all I/O activity, including CPU utilization, run iostat.

  • Examine the /var/adm/messages file for UNIX® system activity or error conditions.

  • Another valuable UNIX tool is SEToolkit. The following tasks in SEToolkit are useful for a portal deployment: toptool.se, zoom.se, tcp_monitor.se, perfmeter.se, limits.se, and webtune.se.

Tuning Sun ONE Portal Server (Core)

The perftune script (in the BaseDir/SUNWps/bin directory), bundled with Portal Server, automates most of the portal tuning process. See the Sun ONE Portal Server 6.0 Installation Guide for details on running perftune.

This section provides additional information on the configuration settings applied by perftune. Except where noted, configuration settings are automatically applied. The parameters shown here that are not configured by perftune are mostly related to monitoring a portal.

Web Container Configuration Settings

The perftune script updates the obj.conf, magnus.conf, and server.xml files in the WEBSERVER/config directory. The web container (in this case, Sun[tm] ONE Web Server) reads these files at startup.

See the following document for additional information:

http://docs.sun.com/source/816-5690-10/index.html

In the magnus.conf file:

  • RqThrottle - Determines the maximum number of threads that the web container will create to service incoming requests. This is set by the perftune script to 256.

  • RqThrottleMin - Determines the initial number of threads created by the web container to service incoming requests. This value should be less than or equal to RqThrottle and is not set by the perftune script. As a rule of thumb, if RqThrottle is set to 256, RqThrottleMin can be set to 128.

  • ThreadIncrement - Determines the number of threads that are created when the web container needs to add more threads. This value is not set by the perftune script. As a rule of thumb, this parameter can be set to 32.

  • StackSize - Determines the size of the stack of each thread that the web container uses to service requests. The perftune script sets this parameter to 384 KB.

  • ConnQueueSize - Determines the number of outstanding (yet to be serviced) connections that the web container can have. This parameter is set by the perftune script to 4,096.

  • ListenQ - Determines the maximum number of pending connections on a listen socket. Connections that time out on a listen socket whose backlog queue is full will fail. This parameter is set by the perftune script to 4,096.

At the end of the magnus.conf file, add the following line:

Init fn="stats-init" profiling="on"

In combination with the parameters added to obj.conf (shown below), this activates the monitoring of performance and thread usage by the web container.

In the server.xml file:

  • acceptorthreads - Determines the number of acceptor threads for the listen socket. The perftune script sets this parameter to a value equal to the number of CPUs in the system. In a building module configuration, this value should be 4.

In the obj.conf file:

The configuration shown below is not applied by perftune, but is used to monitor the performance and thread usage by the web container.

At the beginning of the file:
NameTrans fn=assign-name from="/.perf" name="perf"
NameTrans fn="assign-name" name="stats-xml" from="(/stats-xml|/stats-xml/*)"

In a separate block:
<Object name="perf">
Service fn="service-dump"
</Object>

JVM Parameters

All of these parameters affect the Java HotSpot[tm] JVM. See the following URL for more information:

http://java.sun.com/docs/hotspot/VMOptions.html

  • jvm.minHeapSize and jvm.maxHeapSize - Determine the size of the heap. These parameters correspond to the -ms and -mx parameters of the JVM. For optimum throughput over the long term 1 GB is recommended. For larger deployments use 2 GB.

  • jvm.option=server - Tells the web container to use the server JVM, which is optimized for performance. The -server and -client options invoke two different binaries. They are essentially two different compilers (JITs) interfacing to the same runtime system. The client system is optimal for applications that need fast startup times or small footprints. The server system is optimal for applications where the performance is most important. In general the client system is better on graphical user interfaces. Some of the other differences include the compilation policy used, heap defaults, and inlining policy.

  • jvm.option=-Xrs - Reduces use of OS signals by JVM.

  • jvm.option=-XX:+OverrideDefaultLibthread - Tells the JVM to use the alternate threading model of Solaris[tm] 8. This is the default thread model of Solaris[tm] 9. In summary, the alternate threading model ensures that each Java thread maps to one LWP (which is the unit of scheduling CPUs at the OS level).

  • jvm.option=-XX:PermSize=128M and jvm.option=-XX:MaxPermSize=128M - Together, specify the size of the permanent area of the heap. The permanent generation holds all the reflective data of the JVM itself, such as class and method objects.

  • jvm.option=-XX:NewSize=256M and jvm.option=-XX:MaxNewSize=256M - Specify the size of the new generation out of the total size of the heap. The bigger the young generation, the less often minor collections occur. However, for a bounded heap size, a larger young generation implies a smaller old generation, which increases the frequency of major collections. For Portal Server, it is preferable to have a young generation that is relatively small (one eighth of total heap size) because many objects created by Portal Sever are long-lived and therefore, the earlier they are copied to the old generation, the higher the maximum throughput.

Identity Server Parameters

The perftune script configures parameters for Identity Server that are crucial to achieving maximum throughput and consistent performance.

While the perftune script configures all these parameters programmatically, they can be verified by using a combination of the web-based interface and text editor when troubleshooting any performance issue.

In the serverconfig.xml file:

  • minConnPool and maxConnPool - Define the size of the connection pool used to access the LDAP server.

In the AMConfig.properties file:

  • com.iplanet.am.sdk.cache.maxSize - Specifies the size of the Identity Server cache, an important parameter for portal performance. As stated in "Monitoring Sun ONE Portal Server", achieving an 80 percent cache hit ratio is a basic goal of a production site. For a large deployment, set this value to large number, such as 32,768. The maximum value is 35,000.

  • com.iplanet.am.session.maxSessions - Specifies the maximum number of sessions that the Identity Server accepts. In traditional web applications, this parameter is configured at the web container, by setting the maxSessions value in the web-apps.xml file of the web container. However, for applications that use the Identity Server, this is set in the AMConfig.properties file. The perftune script sets this value to 5,000. The maximum value is 131,072.

See "To Enable Identity Server Performance Statistics" for instructions on turning on logging for Identity Server.

Directory Server Parameters

The perftune script updates the BaseLDAPDir/config/dse.ldif file. This file automatically sets the TCP/IP parameters at boot time. Directory Server reads this file at startup. You need to stop Directory Server before making changes to this file.

Under dn: cn=config:

  • nsslapd-accesslog-logging-enabled - Determines whether Directory Server maintains an access log. While this log is often useful when debugging, you must disable it for a production site, so perftune set this to off.

  • nsslapd-threadnumber - Determines the number of threads that Directory Server makes available to service requests. The perftune script sets this to 75 for a 4-CPU building module.

Under: dn: cn=config,cn=ldbm database,cn=plugins,cn=config:

  • nsslapd-maxthreadsperconn - Determines the maximum number of threads that can be used by a single connection. The perftune script sets this value to 20, which suffices for all portal deployments.

  • nsslapd-db-home-directory - Specifies a subdirectory of a tempfs type file system. The perftune script sets this to /tmp/slapd-dsame1. Because Solaris attempts to map into RAM the contents of the /tmp directory, this parameter has a substantial impact on performance.

TCP Parameters

The perftune script creates the /etc/rc2.d/S99ndd_tcp file. This file automatically sets the TCP/IP parameters at boot time.

  • tcp_time_wait_interval - Specifies the duration in milliseconds that a port remains unavailable after a connection has been closed. This specifies that a new process does not receive packets intended for a process that has since died. On Solaris machines, the default value of tcp_time_wait_interval is 240,000 ms (four minutes). It is recommended that this be set at 60000 ms (1 minute) or even at 30000 (30 seconds) for better performance in socket communication intensive programs. The value can be modified and examined on a running system.

  • tcp_fin_wait_2_flush_interval - Specifies the duration in milliseconds that a connection can stay in the FIN_WAIT_2 state. The recommended value is 60000. Consider decreasing this interval, if netstat -f inet shows many connections in the state FIN_WAIT_2. The timer is used only if the connection is actually idle. Mind that after a TCP half close a simplex data transmission is still available towards the actively closing end.

  • tcp_conn_req_max_q0 - Specifies the maximum number of connections with handshake incomplete. A SYN flood attack could only affect this queue, and a special algorithm makes sure that valid connections can still get through.

  • tcp_conn_req_max_q - Specifies the maximum number of completed connections waiting to return from an accept call as soon as the right process gets some CPU time.

    • In other words, tcp_conn_req_max_q0 specifies the size of the incomplete connection queue while tcp_conn_req_max_q assigns the maximum length of the completed connection queue.

    You can determine if you need to modify this set of parameters by examining the output of the netstat-sPtcp command. Look for the value of tcpListenDrop, if available on your version of Solaris. (Previous versions of Solaris do not have this counter.) Any value showing up might indicate a problem with your server. However, stopping a busy server shuts down its listening socket, and might increase this counter (and others). If you get many drops, you might need to increase the appropriate parameter. Because connections can also be dropped, since listen() specifies a too small argument, you have to be careful interpreting the counter value. On previous versions of Solaris, a SYN flood attack might also increase this counter.

  • tcp_ip_abort_interval - Specifies how long retransmissions for a connection in the ESTABLISHED state should be tried before a RESET segment is sent.

  • tcp_keepalive_interval - Specifies the interval specified before a keep-alive probe can be sent. Keep-alive probes are described in the host requirements RFC 1122. If a host chooses to implement keep-alive probes, it must enable the application to switch them on or off for a connection. Keep-alive probes must be switched off by default.

    • The keep-alive timer becomes significant for web servers, if the client crashes or terminates without the server knowing about it. This condition can be forced sometimes by quickly pressing the stop button of browsers. Thus the keep-alive probes do make sense for web servers.

  • tcp_rexmit_interval_max - Specifies the maximum wait interval between two retransmissions. When changing this value, also inspect the abort interval. The maximum wait interval should only be reached shortly before the abort interval timer expires. Additionally, coordinate your interval with the value of tcp_close_wait_interval.

  • tcp_rexmit_interval_min - Specifies the wait interval for additional retransmissions (after the first one).

  • tcp_rexmit_interval_initial - Specifies the wait interval for the initial retransmission.

  • tcp_slow_start_initial - Provides the slow-start bug discovered in BSD and Windows TCP/IP implementations. To summarize the effect, a server starts sending two PDUs at once without waiting for an ACK due to wrong ACK counts. The ACK from connection initiation is counted as data ACK.

    • Setting the parameter to 2 enables a Solaris machine to behave as though it has the slow start bug, too.

  • tcp_xmit_hiwat - Influences a heuristic that determines the size of the initial send window. The actual value will be rounded up to the next multiple of the maximum segment size (MSS).

  • tcp_recv_hiwat - Determines the maximum size of the initial TCP reception buffer. The specified value will be rounded up to the next multiple of the MSS. From the free space within the buffer the advertised window size is determined, that is, the size of the reception window advertised to the remote peer.

Operating Environment Parameters

The perftune script updates the /etc/system file. This file automatically sets the operating environment parameters at boot time.

  • rlim_fd_max - Defines the hard limit of open files you can have. For most servers, the number of open file descriptors per user process is among the most important parameters. The number of file descriptors is one limit on the number of connections you can have in parallel. You can find out the value of your hard limit on a shell by running the following command:


    • ulimit -Hn

    Consider a value of at least 2 * tcp_conn_req_max and provide at least 2 * rlim_fd_cur, where rlim_fd_cur defines the soft limit of open files you can have. The predicate rlim_fd_cur <= rlim_fd_max must be fulfilled.

  • sq_max_size - Specifies the depth of the syncq (number of messages) before a destination streams queue generates a QFULL. A value of 0 means the number is unlimited.

Tuning Sun ONE Portal Server, Secure Remote Access

The srapperftune script (in the BaseDir/SUNWps/bin/perf directory), bundled with Secure Remote Access, automates most of the gateway tuning process. The following section describes how to manual tune the gateway.

To Edit the Gateway Script

The gateway script is located in the /opt/SUNWps/bin directory.

  1. Edit "CMD" to include the following VM parameters. These numbers are based on a Sun Enterprise[tm] 450 machine with four CPUs and 4096 GB RAM.

    		2.

    -server -Xms1G -Xmx2G -XX:+OverrideDefaultLibthread -XX:ThreadStackSize=128 -XX:MaxPermSize=128M -XX:PermSize=128M -XX:MaxNewSize=256M -XX:NewSize=256M
    1. Remove the native threads option (${NATIVETHREAD}) if it exists.

    2. Allocate the bounded heap size (1 GB) to remove heap free ratio decisions overhead.

    3. Allocate bounded young generation and provision enough eden space to reduce the number of minor collections so that most objects will not survive the first collection while preserving promptness.

      4. This helps support a large number of connected users, and predominance of long-lived objects. Use large heap sizes when the most important JVM performance factor is JVM memory capacity. This is primarily for memory-bound situations.

      Use smaller heap sizes if the most important JVM performance factors are throughput and promptness. This is valid for a small number of connected users with high concurrency. This is primarily for CPU-bound situations.

  2. Prefix the following to LD_LIBRARY_PATH.

    		3.

    LD_LIBRARY_PATH="/usr/lib/lwp:$JAVA_HOME/jre/lib/sparc/server:
    $IPS_HOME/lib/solaris/sparc:$LD_LIBRARY_PATH"

    Using the alternate thread library produces slightly better performance.

To Tune Gateway Logging

  • In the platform.conf.profile file, set logging to error. Time spent logging is decreased and only error messages appear.


    •  

    Note

    This is debug logging.

To Bind to CPUs

  • Bind the gateway process to one CPU (or the number of CPUs as required). This helps track and allocate the resources in a controlled manner.

To Edit the Gateway Profile

To improve gateway performance, use the configuration changes listed here.

  1. Use the Gateway service of the Identity Server administration console to make these changes.

  2. Disable the following settings:
    • Enable Netlet

      • This step is valid only if your deployment does not require Netlet usage. Using the gateway with Netlet disabled gives better performance.

    • Enable Logging

    • Enable Netlet Logging
  3. Set the following:
    • Gateway Timeout to 120000

      • For scenarios with short-lived sessions, you can reduce this value to 30000 or lower as required.

    • Cached Socket Timeout to 120000

      • For scenarios with short-lived sessions, you can reduce this value to 30000 or lower as required.

To Set System Parameters

  • Tune the system by performing the following:
    • In the /etc/system file, set the following parameters:

      		•
      set rlim_fd_max=16384
      set rlim_fd_cur=16384
      set sq_max_size=0
      set tcp:tcp_conn_hash_size=8192

       

      Note

      Restart the machine for changes in /etc/system to take effect.

    • Increase the file descriptors - 16384 has been found to be an optimum value for 1000 to 10,000 users.

    • Stream queue size - This is the depth of the syncq (number of messages) before a destination streams queue generates a QFULL.

    • TCP Connection Hash Size - Should be less than or equal to the number of file descriptors.

See "Operating Environment Parameters" for an explanation of these parameters.

 

Note

You must set the values manually on the gateway machine. The perftune script automates the process on the portal node only.

To Set TCP Parameters from the Command Line

  • Set the following parameters manually each time the machine is rebooted:


    • ndd -set /dev/tcp tcp_time_wait_interval 60000


    ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 60000


    ndd -set /dev/tcp tcp_conn_req_max_q 8192


    ndd -set /dev/tcp tcp_conn_req_max_q0 8192


    ndd -set /dev/tcp tcp_ip_abort_interval 60000


    ndd -set /dev/tcp tcp_keepalive_interval 90000


    ndd -set /dev/tcp tcp_rexmit_interval_max 6000


    ndd -set /dev/tcp tcp_rexmit_interval_min 3000


    ndd -set /dev/tcp tcp_rexmit_interval_initial 500


    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

See "TCP Parameters" for an explanation of these parameters. The settings on the gateway machine should be the same as the portal node. The only difference is that you must set the values manually on the gateway machine; the perftune script automates the process on the portal node.

To Disable Persistent Connections with java.net.HttpURLConnection

Secure Remote Access uses JRE 1.3.1_04 by default. Exceptions related to Session Service or [RemoteConfigServlet] (java.io.EOFException or Read request content error) could be reported in the BaseDir/SUNWam/servers/https-server/logs/errors log when using this JRE.

  • As a workaround, when using this JRE, add the -Dhttp.keepAlive=false system property definition when you invoke the Java launcher for Secure Remote Access.

    • When you disable persistent connections with java.net.HttpURLConnection in this way, you avoid the premature closing of sockets involved in the communication between the gateway and Portal Server nodes. In addition, [RemoteConfigServlet] or SessionService related exceptions do not appear.

To Disable the Secure Remote Access Performance Framework

  • Edit the /etc/opt/SUNWps/perf.conf file and set the following parameter:


    • gateway.perf.enable=false

Secure Remote Access Performance Notes

The section contains additional information on Secure Remote Access Performance.

Non-authenticated URL Paths

When configuring the gateway, you can specify that some URLs do not need any authentication. These are normally directories and folders that contain images. You specify URLs in a Non-authenticated URLs list of the gateway administration module. By so doing, session validation is not performed for any request that falls under this list. Because session validation does not occur, performance should improve. Ideally, you could place all directories that contain images in this list. However, realize that session validation does occur for anything that appears on the Non-authenticated URLs list, so use with caution.

Netlet and Encrypted Algorithms

There are two items that affect Netlet performance:

  • Encrypted algorithm key size

  • The algorithm itself

The higher the encrypted algorithm key length, the higher the security, but the lower the performance. In general, RC4 performs better than AES/Rjindael, TripleDES, and DES. TripleDES gives the worst performance, while Null gives the best performance.

 

Caution

Using Null for your Netlet cipher provides no security. Select Null only if you want a significant performance enhancement, and if you are sure that your users are browsing in a safe environment. 
 
PreviousContentsIndexNext    
Copyright 2003 Sun Microsystems, Inc. All rights reserved.