Building Module Solution Recommendations

This section describes guidelines for deploying your building module solution.

How you construct your building module affects performance.

Consider the following recommendations to deploy your building module properly:

• Deploy a building module on a single machine.

• If you use multiple machines, or if your Portal Server machine is running a large number of instances, use a fast network interconnect.

• On servers with more than eight CPUs, create processor sets or domains with either two or four CPUs. For example, if you choose to install two instances of Portal Server on an eight CPU server, create two four-CPU processor sets.

Directory Server

Identify your Directory Server requirements for your building module deployment. For specific information on Directory Server deployment, see the Directory Server Deployment Guide.

Consider the following Directory Server guidelines when you plan your Portal Server deployment:

• The amount of needed CPU in the Directory Server consumer replica processor set depends on the number of Portal Server instances in the building module as well as performance and capacity considerations.

• If possible, dedicate a Directory Server instance for the sole use of the Portal Server instances in a building module.

• Map the entire directory database indexes and cache in memory to avoid disk latency issues.

• When deploying multiple building modules, use a multi-master configuration to work around bottlenecks caused by the profile updates and replication overhead to the Directory Server supplier.

LDAP

The scalability of building modules is based on the number of LDAP writes resulting from profile updates and the maximum size of the LDAP database.

If the LDAP server crashes with the _db files in the /tmp directory, the files are lost when the server restarts. This improves performance but also affects availability.

If the analysis at your specific site indicates that the number of LDAP write operations is indeed a constraint, some of the possible solutions include creating building modules that replicate only a specific branch of the directory and a layer in front that directs incoming requests to the appropriate instance of portal.

Search Service

When you deploy the Search Engine as part of your building module solution, consider the following:

• In each building module, make sure only one Portal Server instance has the Search Engine database containing the Resource Descriptors (RDs). The remaining Portal Server instances have default empty Search Engine databases.

• Factors that influence whether to use a building module for the portal Search database include the intensity of search activities in a Portal Server deployment, the range of search hits, and the average number of search hits for all users, in addition to the number of concurrent searches. For example, the load generated on a server by the Search Engine can be both memory and CPU intensive for a large index and heavy query load.

• You can install Search on a machine separate from Portal Server, to keep the main server dedicated to portal activity. When you do so, you use the searchURL property of the Search provider to point to the second machine where Search is installed. The Search instance is a normal portal instance. You install the Search instance just as you do the portal instance, but use it just for Search functionality.