Capacity planning and sizing

Average access rates represent a lower bound on how many accesses a given instance of Access Gateway needs to support. You can estimate average access rates by looking at the sets of users that access the system.

To estimate the average access rate, determine:

• Total users: How many users does this instance serve in total? This value represents the total number of users who might ever access the gateway.
• Estimated daily users: The percentage of users who use an application on a given day.
• Estimated daily accesses: The number of times a specific user accesses an application on a specific day.
• Page accesses for each session: For a given set of authenticated users, what is the expected number of page accesses during a single session?

With these concepts in mind, you can estimate an average authentication rate as:

• Average users = Total users / Estimated daily users
• Average accesses = Average users / Estimated daily accesses

Extrapolate overall accesses by examining:

• Overall accesses = Average accesses * Page accesses.

Consider grouping users by the frequency that they access the system:

• Frequent users: Frequent users access the system regularly, typically multiple times per day.
• Infrequent users: Infrequent users access the system on occasion but with a much lower frequency.
• Rare users: Rare users access the system a maximum of one to three times a week.

The following sample demonstrates how to produce an estimate:

• Assume the total number of users is 10,000.
• Frequent average accesses = 10,000 * the number of frequent users.

If we assume that 50% of users are frequent users, then we have a baseline of 5,000.

Frequent users typically access the system at least five times per day. Use this to calculate the number of frequent users as:

• Frequent users * accesses/day = 5 * 5,000 = 25,000

Infrequent users access the system two or three times a day, and represent another 25% of the user base.

• Infrequent users * accesses per day = 10,000 * 25 = 2500 in frequent users each of which accesses the system three times, up a total of 7,500 accesses per day.

Rare users represent the remaining 25% of the user base. These users access the system a maximum of once a day, but typically only access the system every several days.

Rare accesses = total rare users, * total accesses * rarity of access, of once every other day = 2,500 * 1 * .5 = 1,250 total accesses.

You can estimate peak daily uses as:

• Frequent accesses: 25,000
• Infrequent accesses: 7,500
• Rare accesses: 1,250
• This produces a total daily accesses of 33,750.
  
  

When calculating sizing, consider the following areas:

• Cores - Total number of CPUs/cores.
• RAM - Typical memory requirements.
• Storage - How much disk space is required? Primarily for logging purposes.
• NIC - What are throughput requirements?

Terms and definitions:

Term	Description
Application	A reference to an application as defined by the Access Gateway Admin UI console and listed on the Applications page.
Authentication	Authentication or AuthN, is the process of establishing identity. Authentication occurs the first time a user access a given application within Access Gateway. Authentication may also occur at other times when accessing application resources.
Authorization	Authorization, of AuthZ, is the process of determining access rights to a given page or resource. Authorization occurs every time a user attempts to access an application resource such as a page
Session	Access Gateway session or simple session, refers to the information maintained and used by Access Gateway. Typically this includes all the information in a traditional HTTP(s) session as well as Access Gateway specific session data, such as attributes and possibly Kerberos tickets (when in use).

Memory Sizing

Access Gateway appliance memory use is divided into:

• OS, Access Gateway engine, and micro-services, with 1.5GB considered as the minimum for production environments.
• Cached Sessions: 128MB minimum.

Since OS, core Access Gateway, and micro-services memory is fixed, determining memory requirements is primarily focused on cache session sizing.

To determine memory size examine:

• Total sessions - The maximum number of in memory sessions at any given time.
• Average session size - The average expected size of any given session.

Total sessions are calculated using:

• Number of users
• Percentage of user sign-in events per day
• Applications accessed

or

• Total sessions = #users x % sign in per day x applications accessed

Session size is a function of:

• Application session and application attributes, with default size of ~1024b

and

• Kerberos tickets (where applicable), ~1024b, but are often larger based on number of IIS applications accessed

Session cache then becomes:

• Session cache = Total sessions * (average session size * 2)

For example:

Web Application - Session Cache
Users	Percentage sign-in events/Day	Applications Accessed	Total Sessions(Users % logins/day * applications accessed)	Session Size	Session Cache
5,000	50%	5	12,500	1024B*2	~25MB
10,000	75%	10	75,000	1024B*2	~150MB
25,000	50%	100	125,000	1024B*2	~500MB

Kerberos, when used, adds additional caching requirements:

Kerberos Apps - Reserved
Users	Percentage sign-in events/Day	IIS Applications accessed	Total Sessions(Users * logins/day * applications accessed)	Session Size	Session Cache
10,000	50%	5	25,000	1024B	~50MB

Total application memory should then include at least 1.5GB for fixed requirements and session cache plus Kerberos requirements.

Hard Disk Sizing

CPU Sizing

The Access Gateway engine autoscales across CPUs, which results in a worker per CPU. Each additional core results in an additional thread allowing for additional processing.