Sizing

Minimum Sizing

The minimum sizing for an instance of the IAG is defined in the following table:

Please note however that the sizing requirements for each individual environment is different.

Determine the Sizing for an Environment

The sizing for different elements of an IAG container can be impacted by different environmental factors.

Disk

The main factor which impacts the amount of disk space required for an IAG container is the amount of logging which is being sent to disk. If no debug logs are enabled, and the request log is being sent to the console of the container, very little additional disk space is required. However, if any file based logging is enabled it can have a large impact on the amount of disk space required.

Care should be taken to ensure that:

1. The request logging has been configured with a rollover file size, and maximum number of rollover files to help control the amount of disk space consumed by the request log. See the YAML reference for details on how to configure the request log: Request Log. It is however recommended that in most environments the request log is sent to the console of the container so that the log management capabilities of the hosting environment can be used to manage the request log.
2. Debug and trace logs should only be enabled while diagnosing a problem and should not be permanently enabled in an environment.

CPU

The amount of CPU allocated to a container will impact the throughput of the gateway, and will be mostly noticeable when CPU intensive operations (e.g. encryption) are being performed. The CPU utilisation of each individual container should be monitored during periods of heavy activity and adjusted as required.

Memory

The main factors which will impact the memory requirements of the container is the maximum number of concurrent user sessions to be stored by the container, and the amount of response caching which has been configured.

The allocated memory for the container should be roughly large enough to hold the IAG server (approximately 64 Mb), along with a fully populated user session cache and response cache.

Sessions

Each user session can consume up to 7 Kb of memory. The maximum number of sessions which will be stored by the system is controlled by the 'max_sessions' configuration entry. By default this is set to 4096 entries. Once the session cache has reached the maximum configured size older entries will be removed from the cache, making way for a new session, using a Least-Recently-Used (LRU) algorithm. Details on the configuration options which influence the size of the session cache can be found in the YAML reference: Session.

Response Caching

The IAG can cache static web content received from resource servers to increase the performance and response time of requests. By default this caching is disabled, but can be selectively enabled for particular resources. Information on how to configure the response caching can be found in the Caching Responses page.