Scalability in the Deployment Architecture

The modular nature of the reference configuration's deployment architecture
means that you can scale each module independently, depending on the kind
of traffic that your portal service receives.

Each service module in the deployment architecture is composed of two
or more service instances running on separate computers behind a load balancer.
This architecture allows you to scale any of the modules vertically (by adding
CPUs or memory to the host computers) or horizontally (by adding additional
service instances). Some modules are better suited to vertical scaling, and
some modules are better suited to horizontal scaling.

The recommended techniques for scaling each module in the reference
configuration are as follows:

Scaling the directory service module:

Directory
Server scales almost linearly up to 12 CPUs, so vertical scaling is an effective
technique for this module.

A limitation on the performance of Directory Server is the complexity
of the LDAP directory tree. Access Manager creates access control instructions
(ACIs) for each Access Manager organization. Creating multiple organizations
increases the load on Directory Server, as it must process more requests from
Access Manager. At some point (at about 1000 organizations), vertical scaling
is no longer effective.

In that case it becomes more effective to scale horizontally, keeping
the multiple Directory Server instances synchronized by using the Directory
Server's multimaster replication feature. Other approaches include trimming
down the number of ACIs created for each organization and running Access Manager
in realm mode instead of legacy mode. Having thousands of organizations is
not a common requirement, so the reference configuration does not explore
the architectural implications of large numbers of Access Manager organizations.

Scaling the portal and Access Manager service modules:

These modules can be scaled effectively by adding computers running
additional component instances to the module. This approach is cost-effective
and also helps maintain availability because spreading the load over additional
computers ensures that only a relatively smaller amount of capacity will be
lost if a single hardware system fails.

Both Portal Server and Access Manager run in web containers. When they
run in a 32–bit web container, as described in this reference configuration,
the maximum process size is 4 Gbytes of memory, limiting the number of user
session objects that can be stored. If increased memory is needed or increased
throughput is desired, these modules should be scaled horizontally.

It might seem that to better utilize memory (the computers used in the
reference configuration have 16 Gbytes of memory), it would be possible to
run multiple instances on the same hardware. However, this kind of vertical
scaling breaks the modularity of the architecture and does not substantially
increase throughput (the number of pages that are rendered per second).

Scaling the gateway service module:

The Gateway
service can be scaled effectively by adding computers running additional component
instances to the module. This approach is cost effective and also helps maintain
availability because spreading the load over additional computers ensures
that only a relatively smaller amount of capacity will be lost if a single
hardware system fails.