![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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.
The following table provides guidelines for provisioning host computers for AquaLogic Interaction components.
Estimate hardware needs specific to anticipated load. For details, see Evaluating Hardware Requirements for the Portal.
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.
For details on security, see the
Network Security section of the
Networking and Authentication guide.
|
|
|
|
For details on load balancing and failover, see the
Load Balancing section of the
Networking and Authentication guide.
For details on security, see the
Network Security section of the
Networking and Authentication guide.
|
|
For details on load balancing and failover, see the
Load Balancing section of the
Networking and Authentication guide.
For details on security, see the
Network Security section of the
Networking and Authentication guide.
|
|
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.
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.
For details on security, see the
Network Security section of the
Networking and Authentication guide.
|
|
Can reside on same host computer as other components that generate portlets, such as the Publisher, Studio, and Analytics.
Install Collaboration on a separate host computer from other components to preclude contention for the JVM.
For details on load balancing and failover, see the Load Balancing section of the Networking and Authentication guide.
For details on security, see the Network Security section of the Networking and Authentication guide.
|
|
Can reside on same host computer as other components that generate portlets, such as the Collaboration, Studio, and Analytics.
Install Publisher on a separate host computer from other components to preclude contention for the JVM.
No more than one Publisher service should be installed. If capacity is an issue, install Publisher on a separate host with premium hardware.
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.
|
|
Can reside on same host computer as other components that generate portlets, such as the Collaboration, Publisher, and Analytics.
Install Studio on a separate host computer from other components to preclude contention for the JVM.
No more than one Studio service should be installed. If capacity is an issue, install Studio on a separate host with premium hardware.
For details on security, see the
Network Security section of the
Networking and Authentication 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.
|
|
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.
|
|
To maximize performance, install in a network location that is in close proximity to backend data sources.
|
|
To maximize performance, install in a network location that is in close proximity to backend components.
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.
For details on load balancing and failover, see the
Load Balancing section of the
Networking and Authentication guide.
|
The following table characterizes optimization strategies you might consider when you provision computer resources for your site.
Complete the steps in the following worksheet to evaluate hardware options.
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
|
|||
|
|||
Portal performance demonstrates the following general trends:
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.
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:
The following table provides performance data for ALI 6.5.
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.
![]() ![]() ![]() |