Capacity planning and sizing

Average access rates represent a general lower bound on how many accesses a given instance of Access Gateway needs to support. We can estimate average access rates by looking at 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?. Total users represents all users who might ever access the gateway.
• Estimated daily users - The percentage of users who actually use an application in a given day.
• Estimated daily accesses - The number of times a given user accesses an application in a given day.
• Page accesses per sign in - For a given set of authenticated users, how many page accesses are expected during a single session?

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

Average users = Total users / Estimated daily users

Average accesses = Average users / Estimated daily accesses

We can then extrapolate overall accesses by examining:

Overall accesses = Average accesses * Page accesses.

For example, consider three groups of users, each accessing the system, but at different levels.

• 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 1-3 times a week.

For example:

Assume the total number of users as 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 5 times per day. We can calculate frequent users as:

Frequent users * accesses/day = 5 * 5,000, or 25,000.

Infrequent users are defined as those that access the system 2-3 times a day and represent another 25% of the user base.  Accessing the system twice per day.

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 =

2,500 * 1 * .5 (total rare users, * total accesses * rarity of access, of once every other day)  For a total of 1,250 total accesses.

 

We can then estimate peak daily uses as:

• Frequent accesses: 25,000
• Infrequent accesses: 7,500
• Rare accesses: 1,250
• For a total of accesses per day 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.