Usage Analysis for SRA

Use this section only if your organization is implementing a secure portal by installing SRA. As you did for portal, for SRA, you must first establish your Gateway instances baseline sizing estimate (A single machine can have one Gateway installation but multiple instances. SRA enables you to install multiple Gateways, each running multiple instances.) Your design decisions help you make accurate estimates regarding SRA user sessions and concurrency.

You must first establish your Gateway instances baseline sizing estimate. This baseline figure represents what you must have to satisfy your Gateway user sessions and concurrency needs.

Establishing an appropriate sizing estimate for your SRA deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. Test these results against your original requirements. You can avoid most performance problems by formulating your requirements correctly and setting realistic expectations of SRA performance.

Properly sizing the Gateway is difficult, and using the Gateway sizing tool is only the beginning. Gateway performance depends more on throughput then on the number of users, active users, or user sessions. Any sizing information for the Gateway has to be based on a set of assumptions.

Scalability

You can choose between one, two, and four CPUs per Gateway instance. The number of CPUs bound to a Gateway instance determines the number of Gateway instances required for the deployment.

Using SRA Prototype Numbers

If you have numbers from a prototype of the portal with SRA, you can use these numbers in the Gateway sizing tool to arrive at more accurate results. You would fill in the following:

• Measured CPU Performance. The values used to help calculate the number of Gateway instances include:

  • Initial Portal Desktop Display, hits per second per CPU

  • Portal Desktop Reloads, hits per second per CPU

• Netlet Applications Block Size. This value specifies the Netlet application byte size. The Netlet dynamically determines the block size based on the application that is used. Block size determined by Netlet for a Telnet is based on the amount of data transferred.

You do not need to specify the Page Configuration and Scalability options if you are using trial deployment numbers.

Key Performance Factors

Key performance factors are metrics that your technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of Gateway instances your SRA deployment requires.

Identifying these key performance factors and giving them to your technical representative is the first step in formulating your baseline sizing figure.

These are the key performance factors:

• Session Characteristics

• Netlet Usage Characteristics

After you calculate these key performance factors, give the figures to your technical representative. Ask that the Gateway sizing tool be run to identify the estimated number of Gateway instances.

Session Characteristics

The session characteristics of the Gateway include:

• Total number of SRA (Gateway) users

  This represents the size of your user base or pool of potential users for the secure portal..

• Expected percentage of total users using the Gateway (at maximum load)

  Apply a percentage to your total number of users to determine this figure.

• Average time between page hits

  This is how often on average a user requests a page from the portal server.

• Session average time

  This determines how many logins per second that the Gateway must sustain for a given number of concurrent users.

Netlet Usage Characteristics

Consider the following Netlet characteristics of the Gateway, which can have a impact on calculating the number of Gateway instances:

• Netlet is enabled in the Portal Server administration console.

  If Netlet is enabled, the Gateway needs to determine whether the incoming traffic is Netlet traffic or Portal Server traffic. Disabling Netlet reduces this overhead since the Gateway assumes that all incoming traffic is either HTTP or HTTPS traffic. Disable Netlet only if you are sure you do not want to use any remote applications with Portal Server.

• Expected percentage of total users using Netlet

  Apply a percentage to your total number of users to determine this figure.

• Expected throughput

  Determine the expected throughput of your Gateway, expressed in kilobits per second (Kbps).

• Netlet Cipher (encryption) being used

  Choices include Native VM and Java software plugin ciphers.