Sun Java Enterprise System Deployment Planning Guide

Estimating Processor Requirements

This section discusses a process for estimating the number of CPU processors and corresponding memory that are necessary to support the services in a deployment design. The section includes a walkthrough of an estimation process for an example communications deployment scenario.

The estimation of CPU computing power is an iterative process that considers the following:

Logical components and their interactions (as indicated by component dependencies in the logical architecture)
Usage analysis for the identified use cases
Quality of service requirements
Past experience with deployment design and with Java Enterprise System
Consultation with Sun professional services who have experience with designing and implementing various types of deployment scenarios

The estimation process includes the following steps. The ordering of these steps is not critical, but provides one way to consider the factors that affect the final result.

Determine a baseline CPU estimate for components identified as user entry points to the system.

One design decision is whether to fully load or partially load CPUs. Fully loaded CPUs maximize the capacity of a system. To increase the capacity, you incur the maintenance cost and possible downtime of adding additional CPUs. In some cases, you can choose to add additional machines to meet growing performance requirements.

Partially loaded CPUs allow room to handle excess performance requirements without immediately incurring maintenance costs. However, there is an additional up front expense of the under-utilized system.
Make adjustments to the CPU estimates to account for interactions between components.

Study the interactions among components in the logical architecture to determine the extra load required because of dependent components.
Study the usage analysis for specific use cases to determine peak loads for the system, and then make adjustments to components that handle the peak loads.

Start with the most heavily weighted use cases (those requiring the most load), and continue with each use case to make sure you account for all projected usage scenarios.
Make adjustments to the CPU estimates to reflect security, availability, and scalability requirements.

This estimation process provides starting points for determining the actual processing power you need. Typically, you create prototype deployments based on these estimates and then perform rigorous testing against expected use cases. Only after iterative testing can you determine the actual processing requirements for a deployment design.

Example Estimating Processor Requirements

This section illustrates one methodology to estimate processing power required for an example deployment. The example deployment is based on the logical architecture for the identity-based communications solution for a medium-sized enterprise of about 1,000 to 5,000 employees, as described in the section Identity-Based Communications Example.

The CPU and memory figures used in the example are arbitrary estimates for illustration only. These figures are based on arbitrary data upon which the theoretical example is based. An exhaustive analysis of various factors is necessary to estimate processor requirements. This analysis would include, but not be limited to, the following information:

Detailed use cases and usage analysis based on an exhaustive business analysis
Quality of service requirements determined by analysis of business requirements
Specific costs and specifications of processing and networking hardware
Past experience implementing similar deployments

Caution –

The information presented in these examples do not represent any specific implementation advice, other than to illustrate a process you might use when designing a system.

Determine Baseline CPU Estimate for User Entry Points

Begin by estimating the number of CPUs required to handle the expected load on each component that is a user entry point. The following figure shows the logical architecture for an identity-based communications scenario described previously in Identity-Based Communications Example.

Figure 5–1 Logical Architecture for Identity-Based Communications Scenario

Diagram showing logical components for an Identity-based
Communications scenario deployed in a multitiered architecture.

The following table lists the components in the presentation tier of the logical architecture that interface directly with end users of the deployment. The table includes baseline CPU estimates derived from analysis of technical requirements, use cases, specific usage analysis, and past experience with this type of deployment.

Table 5–1 CPU Estimates for Components Containing Access User Entry Points


Component	Number of CPUs	Description
Portal Server	4	Component that is a user entry point.
Communications Express	2	Routes data to Portal Server messaging and calendar channels.

Include CPU Estimates for Service Dependencies

The components providing user entry points require support from other Java Enterprise System components. As you continue to specify performance requirements, add the performance estimates required for supporting components. The type of interactions among components should be detailed when designing the logical architecture, as described in the logical architecture examples in the section Example Logical Architectures.

Table 5–2 CPU Estimates for Supporting Components


Component	CPUs	Description
Messaging Server MTA(inbound)	1	Routes incoming mail messages from Communications Express and e-mail clients.
Messaging Server MTA(outbound)	1	Routes outgoing mail messages to recipients.
Messaging Server MMP	1	Access Messaging Server message store for email clients.
Messaging Server STR(Message Store)	1	Retrieves and stores email messages.
Access Manager	2	Provides authorization and authentication services.
Calendar Server(back-end)	2	Retrieves and stores calendar data for Communications Express, a Calendar Server front-end.
Directory Server	2	Provides LDAP directory services.
Web Server	0	Provides web container support for Portal Serverand Access Manager. (No additional CPU cycles required.)

Study Use Cases for Peak Load Usage

Return to the use cases and usage analysis to identify areas of peak load usage and make adjustments to your CPU estimates.

For example, suppose for this example you identify the following peak load conditions:

Initial ramp up of users as they log on simultaneously
Email exchanges during specified time frames

To account for this peak load usage, make adjustment to the components providing these services. The following table outlines adjustments you might make to account for this peak load usage.

Table 5–3 CPU Estimate Adjustments for Peak Load


Component	CPUs (Adjusted)	Description
Messaging Server MTAinbound	2	Add 1 CPU for peak incoming email
Messaging Server MTAoutbound	2	Add 1 CPU for peak outgoing email
Messaging ServerMMP	2	Add 1 CPU for additional load
Messaging Server STR(Message Store)	2	Add 1 CPU for additional load
Directory Server	3	Add 1 CPU for additional LDAP lookups

Modify Estimates for Other Load Conditions

Continue with your CPU estimates to take into account other quality of service requirements that can impact load:

Security. From the technical requirements phase, determine how secure transport of data might affect the load requirements and make corresponding modifications to your estimates. The following section, Estimating Processor Requirements for Secure Transactions describes a process for making adjustments.
Replication of services. Adjust CPU estimates to account for replication of services for availability, load balancing, and scalability considerations. The following section, Determining Availability Strategies, discusses sizing for availability solutions. The section Determining Strategies for Scalability discusses solutions involving available access to directory services.
Latent capacity and scalability. Modify CPU estimates as necessary to allow latent capacity for unexpected large loads on the deployment. Look at the anticipated milestones for scaling and projected load increase over time to make sure you can reach any projected milestones to scale the system, either horizontally or vertically.

Update the CPU Estimates

Typically, you round up CPUs to an even number. Rounding up to an even number allows you to evenly split the CPU estimates between two physical servers and also adds a small factor for latent capacity. However, round up according to your specific needs for replication of services.

As a general rule, allow 2 gigabytes of memory for each CPU. The actual memory required depends on your specific usage and can be determined in testing.

The following table lists the final estimates for the identity-based communications example. These estimates do not include any additional computing power that could have been added for security and availability. Totals for security and availability will be added in following sections.

Table 5–4 CPU Estimate Adjustments for Supporting Components


Component	CPUs	Memory
Portal Server	4	8 GB
Communications Express	2	4 GB
Messaging Server(MTA, inbound)	2	4 GB
Messaging Server(MTA, outbound)	2	4 GB
Messaging Server(MMP)	2	4 GB
Messaging Server(Message Store)	2	4 GB
Access Manager	2	4 GB
Calendar Server	2	4 GB
Directory Server	4	8 GB (Rounded up from 3 CPUs/6 GB memory)
Web Server	0	0