To Develop a Portal Prototype

1. Identify and remove obvious bottlenecks in the processor, memory, network, and disk.

2. Setup a controlled environment to minimize the margin of error (defined as less than ten percent variation between identical runs).

   By knowing the starting data measurement baseline, you can measure the differences in data performance between sample gathering runs. Be sure measurements are taken over an adequate period of time and that you are able to capture and evaluate the results of these tests.

   Plan to have a dedicated machine for generating load simulation which is separate from the Portal Server machine. A dedicated machine helps you to uncover the origin of performance problems.

3. Define a baseline performance for your deployment, before you add in the full complexity of the project.

4. Using this initial benchmark, define the transaction volume your organization is committed to supporting in the short term and in the long run.

   Determine whether your current physical infrastructure is capable of supporting the transaction volume requirement you have defined.

   Identify services that are the first to reach a maximum volume as you increase the activity to the portal. This indicates the amount of headroom you have as well as identify where to expend your energies.

5. Develop and refine the prototype workload that closely simulates the anticipated production environment agreed between you and the portal administrators and portal developers.

6. Measure and monitor your traffic regularly to verify your prototype.

   Track CPU utilization over time. Load usually comes in spikes and keeping ahead of spikes involves a careful assessment of availability capabilities.

   Most organizations find that portal sites are “sticky” in nature. This means that site usage grows over time, even when the size of the user community is fixed, as users become more comfortable with the site. When the size of the user community also grows over time a successful portal site can see a substantial growth in the CPU requirements over a short period of time.

   When monitoring a portal server’s CPU utilization, determine the average web page latency during peak load and how that differs from the average latency.

   Expect peak loads to be four to eight times higher than the average load, but over short periods of time.

7. Use the model for long-range scenario planning. The prototype can help you understand how dramatically you need to change your deployment to meet your overall growth projections for upcoming years.

8. Keep the error logging level to ERROR and not MESSAGE. The MESSAGE error level is verbose and can cause the file system to quickly run out of disk space. The ERROR level records all error conditions and exceptions.

9. Monitor custom portal applications, such as portlets.

10. Monitor the following areas.

    • Portal Desktop

    • Channel rendering time

    • Sun Java^TM System Access Manager

    • Sun Java System Directory Server

    • Sun Java System Virtual Machine

    • Web container

    The following sections explain issues in terms of portal performance variables and provides guidelines for determining portal efficiency.