Evaluating Hardware for the Portal Component

This appendix describes how to evaluate hardware options for the ALUI portal component so that you can provision hardware with appropriate CPU, RAM, and disk capacity.

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 25%.

Step 6

If the Portal component or server hosting the Portal component performs HTTP compression, subtract 10%.

Step 7

If the conditions in both Step 5 and Step 6 are true--that is, you use SSL without an accelerator and use HTTP compression in the portal component--add 18%.

Step 8

If this Portal component also serves the Administrative Portal, revise the number downward by 5%.

Step 9

If you use a virus scanner on the Portal component, subtract 0-10%, depending on the virus scanner settings.

Step 10

If you deploy the Portal component on a Tomcat Web application server, subtract 20%.

Tomcat does not perform or scale as well as WebLogic, WebSphere, or IIS with .NET. The capacity can be as much as 20% lower than with these alternatives.
Tomcat is also very sensitive to configuration. A poorly tuned Tomcat configuration could perform at less than 50% of the capacity of these other application servers.
Set the following Tomcat configuration variables in the Coyote HTTP 1.1 connector to the following settings for optimal performance:

connectionTimeout = 8000
maxThreads = 100
maxKeepAliveRequests = 1 (disable HTTP 1.1 Keep-Alive)
acceptCount = 500

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

Performance varies significantly on different types of x86 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 G6 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.

System

System Details

Pages/Second

Pentium III Xeon 1.4Ghz, 133 Mhz SDRAM
(Dell PowerEdge 1650)

1 x 1.4Ghz Processor 512K L2

2 x 1.4Ghz Processors 512K

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

2 x 2.4Ghz Processors 512K L2

1 x 2.8Ghz Processor 512K L2

2 x 2.8Ghz Processors 512K L2

1 x 3.06Ghz Processor 512K L21M L3

2 x 3.06Ghz Processor 512K L2 1M L3

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

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

2 x 2.7Ghz Processors 512K L2 2M L3

4 x 2.7Ghz Processors 512K L2 2M L3

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

2 x 1Ghz CPU

4 x 1Ghz CPU

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

Deployment Guide

Evaluating Hardware for the Portal Component

Portal Performance on Various Hardware Hosts