| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E26810-01 |
|
|
View PDF |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E26810-01 |
|
|
View PDF |
This chapter summarizes host configuration and sizing requirements for an Oracle WebCenter deployment. The purpose of this chapter is to assist in planning hardware provisioning for Oracle WebCenter deployment. For further assistance in provisioning hardware, contact your Oracle representative.
The following table provides guidelines for provisioning host computers for Oracle WebCenter components.
| Component | Host Requirements |
|---|---|
|
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 Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
|
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 Oracle WebCenter administrator. |
|
|
Minimum 1 GB RAM Can be installed on the same host computer as the portal component. Recommended 2 GB RAM More processing power is required if you use SSL or compression. Scaling Guide For details on load balancing and failover, see Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
|
Minimum 1 GB RAM Recommended 2 GB RAM Fault tolerant disk for document storage. Scaling Guide For details on load balancing and failover, see Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
|
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 1 GB RAM Dual processor, 1 Ghz or greater Scaling Guide If intensive use of identity service and content service jobs is anticipated, install multiple automation services and configure load balancing. 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 Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
|
Tagging Service |
Minimum 1 GB RAM Recommended 2 GB RAM Fault tolerant disk for document storage. Scaling Guide For details on load balancing and failover, see Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
Notification Service |
Minimum 1 GB RAM Recommended 2 GB RAM Fault tolerant disk for document storage. Scaling Guide For details on load balancing and failover, see Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
Directory Service |
Minimum 1 GB RAM Recommended 2 GB RAM Fault tolerant disk for document storage. Scaling Guide For details on load balancing and failover, see Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
Minimum
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. |
|
|
Minimum 2 GB RAM Dual processor, 2 Ghz Recommended Install on a separate host from the portal component. Scaling Guide No more than one Oracle WebCenter Analytics service should be installed. Security Guide Enable Unicast UDP on port 31314 for communication between Oracle WebCenter Analytics and the portal component. End-user access to Oracle WebCenter Analytics is gatewayed by the portal component, so the Oracle WebCenter Analytics host computer can reside behind a DMZ firewall. |
|
|
Minimum 2 GB RAM Dual processor, 2 Ghz Can reside on same host computer as other components that generate portlets, such as Oracle WebCenter Analytics. Recommended Install Oracle WebCenter 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 Chapter 8, "Load Balancing." Security Guide For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
|
Minimum Can be on the same host as the portal component. Recommended Install on its own host. Scaling Guide No more than one Oracle WebCenter Interaction API service should be installed. Security Guide You should not expose the SOAP API through the extranet. To protect it, install the Oracle WebCenter Interaction API Service on a separate host from the portal component and locate the Oracle WebCenter Interaction API Service host behind a firewall. For details on security, see Chapter 5, "Securing Oracle WebCenter Interaction." |
|
|
Minimum 2 GB RAM 1 CPU, 2 Ghz Recommended 4 GB RAM 2-8 CPU 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. Oracle WebCenter 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 Oracle WebCenter Interaction components can access the database server host. End users do not need access to the database server host. |
|
|
Minimum 1 GB memory 2 GB disk space Dual processor, 1Ghz 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. |
|
|
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 back-end 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. |
|
|
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 back-end 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 Chapter 8, "Load Balancing." 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. |
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 Oracle WebCenter 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 Oracle WebCenter 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. |
Complete the steps in the following worksheet to evaluate hardware options.
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
Review the benchmark charts on Portal Performance on Various Hardware Hosts, and 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.
If users use My Pages more than communities, revise the number upward by approximately 5%.
If users use the Knowledge Directory more than 20% of the time, revise the number downward by approximately 10%.
If the deployment runs under SSL (security mode 2) on the portal component, without an SSL accelerator, subtract 10%.
IF the deployment will use SSL to communicate to the majority of Portlets and Web Services, subtract 10%.
If this portal also serves the administrative portal, revise the number downward by 5%.
If you use a virus scanner on the portal, subtract 0-10%, depending on the virus scanner settings.
If you use Tomcat as the Application Server and do not use the non-blocking Java connector (org.apache.coyote.http11.Http11NioProtocol), subtract 20%.
If the system is deployed as a VMWare Virtual Machine, subtract 15%.
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 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 Oracle WebCenter 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 Oracle WebCenter Interaction 10.3.0. A new benchmark was created for Oracle WebCenter Interaction 10.3.0 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 Oracle WebCenter Interaction 10.3.0.
| 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 |
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
