# Deployment Planning

# Provisioning Computers

This chapter summarizes host configuration and sizing requirements for an AquaLogic User Interaction deployment.

The purpose of this chapter is to assist in planning hardware provisioning for AquaLogic User Interaction deployment. For further assistance in provisioning hardware, contact your BEA representative.

## Component Host Requirements

The following table provides guidelines for provisioning host computers for AquaLogic Interaction components.

Component | Host Requirements
--- | ---
Portal Service | Estimate hardware needs specific to anticipated load. For details, see Evaluating Hardware Requirements for the Portal. Scaling Guide For large deployments, install multiple Portal components and configure load balancing and failover. For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide. Security Guide For details on security, see the Network Security section of the Networking and Authentication guide.
Administrative Portal | Minimum Can additionally function as a Portal component in a Web farm. Can be installed on the same host as Portal component and/or Image Service. If not functioning as a Portal component, can be on the same host as Automation Service. Recommended A dedicated CPU. Some administrative actions are CPU-intensive. Scaling Guide No more than one Administrative Portal should be installed. Security Guide The Administrative Portal can be installed in a network environment that is only accessible by the AquaLogic User Interaction administrator.
Image Service | Minimum 256 MB RAM Can be installed on the same host computer as the Portal component. Recommended 512 MB RAM More processing power is required if you use SSL or compression. Scaling Guide For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide. Security Guide For details on security, see the Network Security section of the Networking and Authentication guide.
Document Repository Service | Minimum 256 MB RAM Recommended 512 MB RAM Fault tolerant disk for document storage. Scaling Guide For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide. Security Guide For details on security, see the Network Security section of the Networking and Authentication guide.
Automation Service | Minimum Should be on a separate host from the Portal component. If installed on the same host as the Portal, schedule all jobs to run in off-peak hours. Recommended Dual processor, 1 Ghz or greater 1 GB RAM Scaling Guide If you anticipate intensive use of identity service and content service jobs, install multiple automation services and configure load balancing. Because search performs document indexing and cannot be horizontally scaled, adding multiple automation services for the sole purpose of crawling content does not greatly improve system performance. For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide. Security Guide For details on security, see the Network Security section of the Networking and Authentication guide.
Search | Minimum Small (up to 250,000 documents) Dual CPU, 2 GB RAM Medium (up to 500,000 documents) Dual CPU, 4GB RAM Two Search Partitions Larger (more than 500,000 documents, or very high search query load) 4 or more Search Partitions with dedicated Dual CPU, 4GB RAM Servers. Or 64-bit Solaris or AIX host (s), Dual CPU 1.3 Ghz or greater; 4-8 GB RAM, high performance I/O. Recommended Two or more x86 Dual CPU Servers with 3GB RAM each configured as a cluster. 64-bit Solaris or AIX host, Dual CPU 1.2 Ghz or greater; 4-8 GB RAM, high performance I/O. Scaling Guide CPU requirements are directly proportional to the search request throughput the component can support. Indexing speed is proportional to the speed of an individual CPU, per Search Partition. RAM supports internal caching done by Search. RAM requirements are proportional to the size and number of documents indexed.
Analytics | Minimum Dual processor, 1 Ghz 1 GB RAM Recommended Install on a separate host from the Portal component. Scaling Guide No more than one Analytics service should be installed. Security Guide Enable Unicast UDP on port 31314 for communication between Analytics and the Portal component. End-user access to Analytics is gatewayed by the Portal component, so the Analytics host computer can reside behind a DMZ firewall.
Collaboration | Minimum Dual processor, 1 Ghz 1 GB RAM Can reside on same host computer as other components that generate portlets, such as the Publisher, Studio, and Analytics. Recommended Install Collaboration on a separate host computer from other components to preclude contention for the JVM. Scaling Guide For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide. Security Guide For details on security, see the Network Security section of the Networking and Authentication guide.
Publisher | Minimum Dual processor, 1.2Ghz 1 GB RAM Can reside on same host computer as other components that generate portlets, such as the Collaboration, Studio, and Analytics. Recommended Install Publisher on a separate host computer from other components to preclude contention for the JVM. Scaling Guide No more than one Publisher service should be installed. If capacity is an issue, install Publisher on a separate host with premium hardware. Security Guide Important! Configure your network to block port 8083 so that end users cannot access the port directly but Publisher components still have access from within the firewall. For more details on security, see the Network Security section of the Networking and Authentication guide.
Studio | Minimum Dual processor, 1Ghz 1 GB RAM Can reside on same host computer as other components that generate portlets, such as the Collaboration, Publisher, and Analytics. Recommended Install Studio on a separate host computer from other components to preclude contention for the JVM. Scaling Guide No more than one Studio service should be installed. If capacity is an issue, install Studio on a separate host with premium hardware. Security Guide For details on security, see the Network Security section of the Networking and Authentication guide.
AquaLogic Interaction API Service | Minimum Can be on the same host as a Portal component. Recommended Install on its own host. Scaling Guide No more than one AquaLogic Interaction API service should be installed. Security Guide You should not expose the SOAP API through the extranet. To protect it, install the AquaLogic Interaction API Service on a separate host from Portal components and locate the AquaLogic Interaction API Service host behind a firewall. For details on security, see the Network Security section of the Networking and Authentication guide.
Database Server | Minimum 1 CPU, 1Ghz 1 GB RAM Recommended 2-8 CPU 4 GB RAM Install on separate host computer. Scaling Guide Database Server Load Balancing The database server can be scaled using any database-compatible clustering technology. Currently, this means that scaling can only be provided by a larger machine. If necessary, each portal database can be placed on a separate computer and scaled separately. If running on Windows, failover of databases can be provided with Microsoft Cluster Services, and geographic load balancing and failover can be provided using SQL Server replication. However, this method is technically and administratively challenging and is not recommended unless availability requirements cannot be met otherwise. Oracle databases can be deployed for high availability. AquaLogic Interaction supports both client-side connection and server-side connection failover with Oracle RAC. Security Guide Install the database server behind a firewall and restrict access so that only computers that host AquaLogic Interaction components can access the database server host. End users do not need access to the database server host.
Remote Server - Identity Services (IDS) | Minimum Dual processor, 1Ghz 1 GB memory 2 GB disk space Recommended Install on a separate host from the Portal component. To maximize performance, install in a network location that is in close proximity to back-end components. Scaling Guide Install additional Automation Services, as necessary, to accommodate a large number of IDS jobs. Security Guide End-user access to IDS portlets is gatewayed by the Portal component, so the IDS host computer can reside behind a DMZ firewall.
Remote Server - Content Services | Minimum Install on a separate host from the Portal component. Recommended To maximize performance, install in a network location that is in close proximity to backend data sources. Scaling Guide Install additional automation services, as necessary, to accommodate a large number of Content Service jobs. Security Guide End-user access to Content Service portlets is gatewayed by the Portal component, so the Content Service host computer can reside behind a DMZ firewall.
Remote Server - Portlets | Minimum Can share a host with other portlets and Web services. Recommended Install on a separate host from the portal component. To maximize performance, install in a network location that is in close proximity to backend components. Scaling Guide In general, caching enables static portlets with minimal personalization to scale very well to any number of users. Dynamic portlets with more personalization cannot be as effectively cached and so require more processing power. If necessary, improve performance by installing dynamic portlets on hosts with premium hardware. Remote Server Load Balancing Remote servers can be load balanced using Parallel Portal Engine load balancing. For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide. Security Guide End-user access to portlets is gatewayed by the Portal component, so the remote server host computer for portlets can reside behind a DMZ firewall.

## Optimization Strategies

The following table characterizes optimization strategies you might consider when you provision computer resources for your site.

Goal | Approach
--- | ---
Low initial hardware cost | Organizations optimizing for low initial hardware cost seek to buy the least expensive machines necessary to make the software work reliably. Given a choice between repurposing two existing single processor servers and spending $7,000 on a new multi-processor, multi-core server, they would choose the former.
Low hardware maintenance cost | Organizations optimizing for low hardware maintenance costs seek to reduce the number of machines needed to host the software. Because each additional computer incurs a minimum fixed cost in terms of administrative overhead, power consumption, space, and operating system license, these organizations would rather combine multiple ALUI components on a single, more powerful computer than distribute those components over multiple, less expensive machines.
High availability | Organizations optimizing for high availability are willing to spend extra money and effort to ensure that the portal and other ALUI components are available reliably to their users at all times. Such organizations typically purchase more computers and load balance them where possible, creating redundant configurations.
Low software maintenance cost | Organizations optimizing for low software maintenance cost assume that at some point in the life of the system, some part of the software will malfunction, and they seek both to lessen the chance that malfunctions will occur and lessen their impact when they do occur. Such organizations would typically purchase more individual computers to ensure that system components do not interfere with one another, and to reduce the risk that taking a computer out of the system to install new software will impact multiple system functions.
Scalability | Organizations optimizing for scalability assume that their deployments will be required to handle a large number of users. Such organizations would typically purchase extra hardware, and more expensive hardware, in order to create excess capacity in the system.
Performance | Organizations optimizing for performance seek to make their systems operate as fast as possible, especially in their ability to render pages quickly for end-users. Like organizations seeking to lower software maintenance costs, these organizations would distribute system components across a larger number of computers to ensure that each component has unrestricted access to the computing power it needs to perform its tasks the moment those tasks are called for.
Network Security | Organizations optimizing for network security seek to ensure that end-users touch only machines hosting the smallest amount of code and data. Such organizations also typically install firewalls between layers of their deployment, to ensure that if an intruder compromises one layer, the potential damage is limited. Such organizations tend to purchase more computers in order to isolate the Portal component, which end-users touch directly, from other components.

## Evaluating Hardware Requirements for the Portal

Complete the steps in the following worksheet to evaluate hardware options.

Step | Calculation
--- | ---
Step 1 | Estimate peak load using the following calculation: `Pages/sec = ((Power user pages/hr * #power users + Normal user pages/hr * #normal users + Infrequent user pages/hr * #infrequent users pages/hr) / (3600 sec/hr) * fraction of users who could log on who are actually connected`
Note: | Base your calculations on historical data for existing Web sites that serve a similar function. Use the following conventions to identify users:
Power users. A power user is one who routinely adds or deletes portal content. Normal users. A normal user is one who routinely reads content. Infrequent users. An infrequent user is one who does not routinely use the portal. Record your estimated peak load here: ____________ pages/sec
Step 2 | Review the benchmark charts on Portal Performance on Various Hardware Hosts. Choose a configuration that supports the peak load calculation from Step 1. In general, you want to provision a number of portal components that support a total of 2 to 3 times the estimated peak load from Step 1. For example, if you estimate peak load to be 15 pages/sec, you want to provision either: One (1) portal component that can support 30-45 pages/sec Two (2) or three (3) portal components that each support 15 pages/sec. Record the benchmark capacity here: ____________ pages/sec Follow the steps described in Steps 3-10 to adjust this benchmark capacity to a real-life estimate of expected use.
Step 3 | If users use My Pages more than communities, revise the number upward by approximately 5%.
Step 4 | If users use the Knowledge Directory more than 20% of the time, revise the number downward by approximately 10%.
Step 5 | If the deployment runs under SSL (security mode 2) on the portal component, without an SSL accelerator, subtract 10%.
Step 6 | IF the deployment will use SSL to communicate to the majority of Portlets and Web Services, subtract 10%.
Step 7 | If this portal also serves the administrative portal, revise the number downward by 5%.
Step 8 | If you use a virus scanner on the portal , subtract 0-10%, depending on the virus scanner settings.
Step 9 | If you use Tomcat as the Application Server and do not use the non-blocking Java connector (org.apache.coyote.http11.Http11NioProtocol), subtract 20%.
Step 10 | If the system is deployed as a VMWare Virtual Machine, subtract 15%.
Step 11 | After you have made the adjustments in Steps 3-10, does the configuration you selected in Step 2 still meet your capacity requirements?

## Portal Performance on Various Hardware Hosts

Portal performance demonstrates the following general trends:

- Performance varies significantly on different types of server hardware.
- Performance is not dependent on the operating system, where platforms are otherwise similar.
- Performance is dependent on the JVM or CLR used and how these are tuned.
- In general, .NET and Java show similar performance, being nearly equal on most two-processor servers. However these vary somewhat in the sensitivity to processor frequency and system memory performance:

- Java tends to be more sensitive to system memory performance.
- .NET is more sensitive to processor cache size and processor frequency.

These differences run approximately within a plus or minus 20% performance range at the very extreme.

- Overall performance is highly dependent on memory subsystem performance, which tends to be the most important performance-related property of a server. Memory subsystem performance can be characterized by the total aggregate system bandwidth to memory as well as the latency of memory access. For Intel Xeon-based systems, this is correlated with the processor bus speed. Systems with a 800Mhz bus significantly outperform those with a 400Mhz bus. Pentium III Xeon-based systems are also limited by their memory subsystem and scale poorly with extra CPUs.

The performance data in the table that follows is indicative of these general trends. This table provides benchmark data for the current version of the AquaLogic Interaction portal component. For each representative system, the load shown is the maximum sustainable load on the server with an average mix of page views on an uncustomized system. Various factors will influence the maximum sustainable load of individual deployments such as UI customizations, effective use of portlet caching, and different mixes of page types.

### Pages per Second on AquaLogic Interaction 6.5

It is important that the performance measurements in the following table not be compared directly with the performance data for releases earlier than AquaLogic Interaction 6.5. A new benchmark was created for AquaLogic Interaction 6.5 that does more work per request and serves more sophisticated content than the previous benchmarks. In addition to richer content and more data in the system, HTTP compression is enabled and approximately 25% of the portlet request occur via HTTPS. Adaptive Layout mode is enabled for the benchmark.

The page distribution in the benchmark is approximately:

- 10% My Pages
- 30% Communities
- 10% Knowledge Directory
- 10% Searches
- 5% User Profiles
- 30% Gateway
- 5% other

The following table provides performance data for ALI 6.5.

System | System Details | Pages/Second
--- | --- | ---
Xeon 2.4Ghz to 3.06Ghz, 533Mhz system bus, HyperThreading enabled (Dell PowerEdge 1750) | 2 x 2.8Ghz Processors 512K L2 | 41
Xeon 3.2Ghz, 800Mhz system bus, HyperThreading enabled (Dell PowerEdge 1850) | 2 x 3.2Ghz Processors 1M L2 | 67
Xeon MP 2.7Ghz, 400Mhz system bus, HyperThreading enabled (Dell PowerEdge 6650) | 4 x 2.7Ghz Processor 512K L2 2M L3 | 67
Xeon 2.66Ghz, 1333Mhz system bus (Dell PowerEdge 1950) | 4x2.66 Ghz Core 2 Xeon Dual Core | 125
Opteron 2.2Ghz, 1000 MHz | 2x2.2 Ghz Opteron Dual Core | 105
UltraSparc IV 1.5Ghz Sun Fire V490 | 2 x 1.5 Ghz CPU | 71
UltraSPARC-T1 1 GHz Sun Fire T1000 | 8 cores 32 threads 1GHz | 74

### Pages per Second on AquaLogic Interaction 6.1

The following table provides performance data for ALI 6.1. The benchmark used is different than that used in the previous section. Data from this table should not be compared to the ALI 6.5 performance data.

System | System Details | Pages/Second
--- | --- | ---
Pentium III Xeon 1.4Ghz, 133 Mhz SDRAM (Dell PowerEdge 1650) | 1 x 1.4Ghz Processor 512K L2 | 33
2 x 1.4Ghz Processors 512K | 44
Xeon 2.4Ghz to 3.06Ghz, 533Mhz system bus, HyperThreading enabled (Dell PowerEdge 1750)
Note: | Mhz is less important than total processor cache for performance. Disabling HyperThreading decreases performance 12% with two CPUs and 25% with one.
| 1 x 2.4Ghz Processor 512K L2 | 56
2 x 2.4Ghz Processors 512K L2 | 71
1 x 2.8Ghz Processor 512K L2 | 58
2 x 2.8Ghz Processors 512K L2 | 73
1 x 3.06Ghz Processor 512K L21M L3 | 67
2 x 3.06Ghz Processor 512K L2 1M L3 | 82
Xeon 3.2Ghz, 800Mhz system bus, HyperThreading enabled (Dell PowerEdge 1850)
Note: | The 800Mhz bus improves the performance of Xeon-based systems greatly. Disabling HyperThreading decreases performance by approximately 15% for dual-CPU systems and 25% for single CPU systems.
| 1 x 3.2Ghz Processor 1M L2 | 75
2 x 3.2Ghz Processors 1M L2 | 100
Xeon MP 2.7Ghz, 512K L2 2M L3 caches, 400Mhz system bus, HyperThreading enabled (Dell PowerEdge 6650)
Note: | The 400Mhz bus of this system severely limits performance. This system is the only one with large differences in performance between .NET and Java platforms: .NET performs 25% better than the performance indicated here for the 4 processor node and performs equally well as Java for one processor.
| 1 x 2.7Ghz Processor 512K L2 2M L3 | 34
2 x 2.7Ghz Processors 512K L2 2M L3 | 53
4 x 2.7Ghz Processors 512K L2 2M L3 | 66
UltraSparc III 1.0Ghz (Sun Fire 280R)
Note: | Most Sun systems scale the memory bandwidth with each CPU, and will scale well with increased CPU count.
| 1 x 1Ghz CPU | 27
2 x 1Ghz CPU | 50
4 x 1Ghz CPU | 90
Power 5 1.5Ghz (IBM iSeries 520)
Note: | Power 5 based IBM systems scale memory with each pair of CPUs, and performance will scale with CPU count as a result.
| 2 x 1.5Ghz CPU | 70