Sun ONE logo     Previous      Contents      Index      Next     
Sun ONE Portal Server 6.0 Deployment Guide



Chapter 5   Sizing Your Portal

This chapter describes how to establish a baseline sizing figure for your portal, and optionally, your gateway. With a baseline figure established, you can then refine that figure to account for scalability, high availability, reliability, and good performance.

This chapter contains the following sections:

Overview of the Portal Sizing Process

There are four steps to the portal sizing process. You must execute these steps in sequence to determine the best sizing estimate for a specific Sun™ ONE Portal Server deployment. The four steps include:

  1. Determining the key performance requirements

  2. Using the sizing tool to generate first cut recommendation

  3. Determining the other factors affecting sizing

  4. Refining the sizing


    5. Note

    You need to work with your Sun ONE technical representative to use the sizing tool.

If you are deploying both core Portal Server and Sun™ ONE Portal Server, Secure Remote Access, you would follow this sequence of steps twice, once for each product.

The following sections describe these steps in detail.

Establishing Baseline Sizing Figures (Core Portal)

Once you have identified your business and technical requirements, and mapped Portal Server features to those needs, your sizing requirements will emerge as you plan your overall Portal Server deployment. Your design decisions will help you make accurate estimates regarding Portal Server user sessions and concurrency.


Note

Sizing requirements for a secure portal deployment using Secure Remote Access are covered in "Establishing and Refining Sizing Figures (Secure Remote Access)".

You must first establish your core baseline sizing estimate. This baseline figure represents what you must have to satisfy your user sessions and concurrency needs.

Establishing an appropriate sizing estimate for your Portal Server deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. You will then want to test these results against your original requirements. You can avoid most performance problems by formulating your requirements correctly and setting realistic expectations of Portal Server performance.

This section explains the following types of performance factors that the baseline sizing process involves:

Identifying Key Performance Requirements

Key performance factors are metrics that your Sun ONE technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of CPUs your core Portal Server deployment requires.

Identifying these key performance factors and giving them to your Sun ONE technical representative is the first step in formulating your baseline sizing figure.

These are the key performance factors:

Concurrent Sessions

Maximum number of concurrent sessions defines how many connected users a Portal Server deployment can handle.

To calculate your maximum number of concurrent sessions, use this formula:

maximum number of concurrent sessions =
expected percent of users online * user base

To identify the size of your user base or pool of potential users for an enterprise portal, use these suggestions:

  • Identify only users who are active. Do not include users who are, for example, away on vacation, or on leave.

  • Use a finite figure for user base. For an anonymous portal, estimate this number conservatively.

  • Study access logs.

  • Identify the geographic locations of your user base.

  • Remember what your business plan states regarding who your users are.

Average Time Between Page Requests

Average time between page requests is how often on average a user requests a page from the portal server. Pages could be the initial login page to the portal, or a web site or web pages accessed through the Desktop. A page view is a single call for a single page of information no matter how many items are contained on the page.

Though web server logs record page requests, in general it is not feasible to use the log to calculate the average time between requests on a user basis. To calculate the average time between page requests, you would probably need a commercially available statistics tool, such as the WebLoad performance testing tool. You can then use this figure to determine the number of concurrent users.


Note

Page requests more accurately measure web server traffic than "hits." Every time any file is requested from the web server counts as a hit. A single page call can record many hits, as every item on the page will be registered. For example, a page containing 10 graphic files will record 11 "hits"—one for the HTML page itself and one for each of the 10 graphic files. For this reason, page requests gives a more accurate determination of web server traffic.

Concurrent Users

A concurrent user is one connected to a running web browser process and submitting requests to or receiving results of requests from Portal Server. The maximum number of concurrent users is the highest possible number of concurrent users within a predefined period of time.

Calculate maximum number of concurrent users after you calculate maximum number of concurrent sessions. To calculate the maximum number of concurrent users, use this formula:

concurrent users =
number of concurrent sessions / average time between hits

For example, consider an intranet Portal Server example of 50,000 users. The number of connected sessions under its peak loads is estimated to be 80% of its registered user base. On average, a user accesses the Desktop once every 10 minutes.

The calculation for this example is:

40000 / 10 = 4000

The maximum number of concurrent users during the peak hours for this Portal Server site should be 4,000.

Average Session Time

Average session time is the time between user login and logout averaged over a number of users. The length of the session time is inversely proportional to the number of logins occurring (that is, the longer the session duration, the fewer logins per second are generated against Portal Server for the same concurrent users base). Session time is the time between user login and user logout.

How the user uses Portal Server often affects average session time. For example, a user session involving interactive applications typically has a longer session time than a user session involving information only.


Tip

If your portal site will not offer a Search channel, you do not need to prepare figures in the "Search Engine Factors" section below. You can now give the above figures to your Sun ONE technical representative and ask that the sizing tool be run to identify your estimated number of CPUs.

Search Engine Factors

If your portal site will offer a Search channel, you need to include sizing factors for the Search Engine in your sizing calculations. Search Engine sizing requirements depend on the following factors:

  • The size of index partitions on the active list of the index directory

    • Partition size is directly proportional to the size and number of indexed and searchable terms.

  • Average disk space requirement of a resource description (RD)

    • To calculate this, use this formula:

    average disk space requirement =
    database size / number of RDs in database

    The average size adjusts for variations in sizes of RDs. A collection of long, complex RDs with many indexed terms and a list of short RDs with a few indexed terms require different search times, even if they have the same number of RDs.

    RDs are stored in a hierarchical database format, where the intrinsic size of the database must be accounted for, even when no RD is stored.

  • The number of concurrent users who perform search-related activities

    • To calculate this, use this formula:

    number of concurrent users / average time between search hits

    Use the number of concurrent users value calculated in ""Average Time Between Page Requests"."

  • The type of search operators used

    • Types of search functions include basic, combining, proximity, passage and field operator, and wildcard scans. Each function uses different search algorithms and data structures. Because differences in search algorithms and data structures increase as the number of search and indexed terms increase, they affect times for search result return trips.


    Tip

    You can now give the above figures to your Sun ONE technical representative and ask that the sizing tool be run to identify your estimated number of CPUs.

Applying Related Factors

Related performance factors are metrics that affect the number of CPUs a Portal Server deployment requires but that are not used in the automated sizing tool.

Identifying these related performance factors is the second step in formulating your baseline sizing figure.

These are the related performance factors:

Desktop Configuration

Desktop configuration explicitly determines the amount of data held in memory on a per-session basis.

The more channels on the Desktop, the bigger the size of the session data is, and the lesser the throughput of Portal Server.

Another factor is how much interactivity the Desktop offers. For example, channel clicks can generate load on Portal Server or on some other external server. If channel selections generate load on Portal Server, a higher user activity profile and higher CPU overhead occurs on the node that hosts the Desktop than on a node that hosts some other external server.

Customization

Customizing your Portal Server deployment can greatly affect its performance.

Whenever you implement authentication modules and custom channels, use a trial deployment to determine your final sizing estimates.

You also must use a trial deployment to size back-end integration, to avoid potential bottlenecks with Portal Server operations.

Hardware and Applications

CPU speed and size of the virtual machine for the Java™ platform (Java™ Virtual Machine or JVM™ software) memory heap affect Portal Server performance.

The faster the CPU speed, the higher the throughput. The JVM memory heap size, along with the heap generations tuning parameters, can affect Portal Server performance. See Chapter 8 "Monitoring and Tuning Your Portal" for more information on JVM memory heap size.

Back-end Servers

Portal Server aggregates content from external sources. If external content providers cannot sustain the necessary bandwidth for Portal Server to operate at full speed, Desktop rendering and throughput request times will not be optimum. The Desktop waits until all channels are completed (or timed out) before it returns the request response to the browser.

Plan your back-end infrastructure carefully when you use channels that:

  • Scrape their content from external sources

  • Access corporate databases, which typically have slow response times

  • Provide email content

  • Provide calendar content

Transaction Time

Transaction time, which is the delay taken for an HTTP or HTTPS operation to complete, aggregates send time, processing time, and response time figures.

You must plan for factors that can affect transaction time. These include:

  • Network speed and latency. You need to especially examine latency over a Wide Area Network (WAN). Latency can significantly increase retrieval times for large amounts of data.

  • The complexity of the Desktop.

  • The browser's connection speed. For example, a response time delay is longer with a connection speed of 33.6 kilobytes per second than with a LAN connection speed. However, processing time should remain constant. Transaction time through a dial-up connection should be faster than transaction time displayed by a load generation tool because it performs data compression.

When you calculate transaction time, size your Portal Server so that processing time under regular or peak load conditions does not exceed your performance requirement threshold and so that you can sustain processing time over time.

Workload Conditions

Workload conditions are the most predominantly used system and JVM software resources on a system. These conditions largely depend on user behavior and the type of portal you deploy.

The most commonly encountered workload conditions on Portal Server software are those that affect:

  • System performance

    • Portal Server performance is impacted when a large number of concurrent requests are handled (such as a high activity profile). For example, during peak hours in a business-to-enterprise portal, a significant number of company employees connect to the portal at the same time. Such a scenario creates a CPU-intensive workload. In addition, the ratio of concurrent users to connected users is high.

  • System capacity

    • Portal Server capacity begins to be impacted when large numbers of users log in. As more users log in, they use up more of the available memory, and subsequently, less memory is available to process requests made to the server itself. For example, in a business-to-consumer web portal, a large number of logged-in users are redirected to external web sites once the initial Desktop display is loaded. However, as more users continue to log in, they consequently create the need for more memory, even though the ratio of users submitting requests to Portal Server and those merely logged-in is low.

    Depending on the user's behavior at certain times of the day, week, or month, Portal Server can switch between CPU-intensive and memory-intensive workloads. The portal site administrator must determine the most important workload conditions to size and tune the site to meet the enterprise's business goals.

LDAP Transaction Numbers

Use the following LDAP transaction numbers for an out-of-the-box portal deployment to understand the impact of the service demand on the LDAP master and replicas. These numbers will change once you being customizing the system.

  • Access to authless anonymous portal - 0 ops

  • Login by using the Login channel - 2 BINDS, 2 SRCH

  • Removing a channel from the Desktop - 8 SRCH, 2 MOD

  • Reloading the Desktop - 0 ops

Application Server Requirements

One of the primary uses of Portal Server installed on an application server is to integrate portal providers with Enterprise JavaBeans™ and other J2EE™ technology stack constructs, such as JDBC and JCA, running on the application server. These other applications and modules can consume resources and affect your portal sizing.

Refining Baseline Sizing Figures (Core Portal)

Once you have established your core portal baseline sizing figure by estimating your CPU requirements and by identifying related factors, your next step is to refine your sizing figure. In this section, you build in the appropriate amount of headroom so that you can deploy a portal site that features scalability, high availability, reliability, and good performance.


Note

Refining baseline sizing requirements for a secure portal deployment using Secure Remote Access is covered in "Establishing and Refining Sizing Figures (Secure Remote Access)".

Because your baseline sizing figure is based on so many estimates, do not use this figure without refining it.

When you refine your baseline sizing figure:

  • Use your baseline sizing figure as a reference point.

  • Expect variations from your baseline sizing figure.

  • Learn from the experience of others.

  • Use your own judgement and knowledge.

Considering these factors enables you to develop a sizing figure that is flexible and enables you to avoid risk when your assumptions regarding your portal change following deployment.

To refine your baseline sizing estimate, complete the following steps:

  1. Apply the SHARP factor to your baseline sizing figure.

    2. The acronym SHARP stands for scalability, high availability, reliability, and good performance. Applying the SHARP factor to your baseline sizing figure enables you to deploy a portal site with these features and enables you to have room for everything else you want to provide.

    To calculate your final sizing figure applying the SHARP factor, use this rule of thumb:

    final CPU figure = estimated number of CPUs * n

    The estimated number of CPUs value is a result of the sizing tool calculations made by your Sun ONE technical representative. (For more information about this value, see "Identifying Key Performance Requirements".)

  2. The n value in this rule varies, according to whatever leeway is needed for variations in factors such as concurrent users or peak time. You must set the n value according to whatever your portal site's priorities are. The goal is that estimated number of CPUs be no lower than final CPU figure.


    3. Tip

    Portal Server deployment experience has shown that the value of n usually falls somewhere between 1 and 3.

    Here are two examples of applying this rule of thumb:

Core Portal Example 1

Consider a Portal Server solution for 10,000 users and 3,000 concurrent user sessions. With back-end latency that can sustain 500 users for each CPU, a minimum of six CPUs are needed. If you determine that a SHARP factor of *1.5 is appropriate, this is the calculation for identifying the final CPU figure:

6 * 1.5 = 9

This deployment requires a minimum of nine CPUs.

Core Portal Example 2

Using the same user and session figures but with back-end latency that can sustain 2,000 users for each CPU, a minimum of three CPUs are needed. If you determine that a SHARP factor of *2 is appropriate, this is the calculation for identifying the final CPU figure:

3 * 2 = 6

This deployment requires a minimum of six CPUs.

  1. Examine other factors in your deployment.

    2. If the Portal Server deployment involves multiple data centers on several continents and even traffic, you will want a higher final sizing figure than if you have two single data centers on one continent with heavy traffic.

  2. Plan for changes.

    3. A portal site is likely to experience various changes after you launch it. Changes you might encounter include the following:

    • An increase in the number of channels

    • Growth in the user base

    • Modification of the portal site's purpose

    • Changes in security needs

    • Power failures

    • Maintenance demands

The resulting figure ensures that your portal site will have:

  • Scalability, high availability, reliability, and high performance

  • Room for whatever you want to provide

  • Flexibility for adjusting to changes

Establishing and Refining Sizing Figures (Secure Remote Access)

Use this section only if your organization is implementing a secure portal by installing Secure Remote Access. As you did for core portal, for Secure Remote Access you must first establish your gateway instances baseline sizing estimate. (A single machine can have one gateway installation but multiple instances. Secure Remote Access enables you to install multiple gateways, each running multiple instances.) Your design decisions will help you make accurate estimates regarding Secure Remote Access user sessions and concurrency.

You must first establish your gateway instances baseline sizing estimate. This baseline figure represents what you must have to satisfy your gateway user sessions and concurrency needs.

Establishing an appropriate sizing estimate for your Secure Remote Access deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. You will then want to test these results against your original requirements. You can avoid most performance problems by formulating your requirements correctly and setting realistic expectations of Secure Remote Access performance.

This section explains the following types of performance factors that the gateway instances baseline sizing process involves:

Identifying Gateway Key Performance Requirements

Key performance factors are metrics that your Sun ONE technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of gateway instances your Secure Remote Access deployment requires.

Identifying these key performance factors and giving them to your Sun ONE technical representative is the first step in formulating your baseline sizing figure.


Note

Properly sizing the gateway is difficult, and using the gateway sizing tool is only the beginning. Gateway performance depends more on throughput then on the number of users, active users, or user sessions. Any sizing information for the gateway has to be based on a set of assumptions. See "Secure Remote Access Example" fore more information.

These are the key performance factors:

  • Session Characteristics

  • Netlet Characteristics


    • Note

    After you calculate these key performance factors, give the figures to your Sun ONE technical representative. Ask that the gateway sizing tool be run to identify the estimated number of gateway instances.

Session Characteristics

The session characteristics of the gateway include:

  • Total number of Secure Remote Access (gateway) users

    • This represents the size of your user base or pool of potential users for the secure portal. See "Concurrent Sessions" for more information on estimating this number.

  • Expected percentage of total users using the gateway (at maximum load)

    • Apply a percentage to your total number of users to come up with this figure.

  • Average time between page hits

    • This is how often on average a user requests a page from the portal server. See "Average Time Between Page Requests" for more information.

  • Session average time

    • This determines how many logins per second that the gateway must sustain for a given number of concurrent users. See "Average Session Time" for more information.

Netlet Characteristics

Consider the following Netlet characteristics of the gateway, which can have a impact in calculating the number of gateway instances:

  • Netlet Enabled in Admin Console

    • If Netlet is enabled, the gateway needs to determine whether the incoming traffic is Netlet traffic or Portal Server traffic. Disabling Netlet reduces this overhead since the gateway assumes that all incoming traffic is either HTTP or HTTPS traffic. Disable Netlet only if you are sure you do not want to use any remote applications with Portal Server.

  • Expected percentage of total users using Netlet

    • Apply a percentage to your total number of users to come up with this figure.

  • Expected throughput

    • Determine the expected throughput of your gateway, expressed in kilobits per second (Kbps).

  • Netlet Cipher being used

    • Choices include Null, RC4, AES/Rijndael, DES, and TripleDES.

Advanced Gateway Settings

Use the settings in this section to obtain more accurate results when estimating the number of gateway instances for your deployment. These advanced gateway settings are used as input to the automated sizing tool.

These are the advanced gateway settings:

Page Configuration

If you are using an authenticated portal, you must specify both Login Type and Desktop Type in the page configuration section of the automated sizing tool.

  • Login Type - Describes the type of portal page (content configuration and delivery method) that end users initially see after submitting username and password. Because this process involves checking credentials, initializing the session, and delivering initial content, it is typically more taxing on the system.

    • The Measured CPU Performance characteristic associated with the Login Type is the Initial Desktop Display variable.

  • Desktop Type - Describes the type of portal pages (content configuration and delivery method) that end users see after the initial portal page. These pages are displayed with each subsequent interaction with the portal, or on Desktop refresh. Because the session has already been established and cached content can be exploited, less system resources are typically required and the pages are delivered more rapidly.

    • The Measured CPU Performance characteristic associated with the Desktop Type is the Desktop Reload variable.

For both Login Type and Desktop Type, select the appropriate content configuration:

  • Light - JSP - Describes a configuration of two tabs with five channels each.

  • Regular - JSP - Describes a configuration of two tabs with seven channels each.

  • Heavy - JSP - Describes a configuration of three tabs with seventeen channels each.

Scalability

You can choose between one, two, and four CPUs per gateway instance. The number of CPUs bound to a gateway instance determines the number of gateway instances required for the deployment.

Secure Portal Pilot Measured Numbers

If you have numbers from a pilot of the Secure Remote Access portal, you can use these numbers in the gateway sizing tool to arrive at more accurate results. You would fill in the following:

  • Measured CPU Performance - The values used to help calculate the number of gateway instances include:

    • Initial Desktop Display, in hits per second per CPU

    • Desktop Reloads, hits per second per CPU

  • Netlet Applications Block Size - This value specifies the Netlet application byte size. The Netlet dynamically determines the block size based on the application that is used. For example, block size determined by Netlet for a Telnet application will be different from that of FTP. It is based on the amount of data transferred. The acceptable values are:

    • 1 Byte

    • 2 Bytes

    • 4 Bytes

    • 16 Bytes

    • 32 Bytes

    • 64 Bytes

    • 128 Bytes

    • 512 Bytes


      • Note

      You do not need to specify the Page Configuration and Scalability options if you are using trial deployment numbers

Here are two examples for Secure Remote Access:

Secure Remote Access Example

Consider a Secure Remote Access solution for 25,000 users, with 5,000 peak concurrent users and 200 peak active users. Assume an average request/response time to be 50 Kbytes per second (for light Desktop usage). The peak throughput would then be:

peak throughput = # peak active users * average request/response

or

200 * 50 Kbytes = 10,000 Kbytes per second

Now assume a Secure Remote Access performance base line to be 640 Kbytes per Secure Remote Access per CPU per second. You can then calculate the number of Secure Remote Access CPUs needed as follows:

# Secure Remote CPUs = Peak Throughput / SRA baseline

or

10,000 Kbytes / 640 Kbytes = 16 CPUs

In addition, two Secure Remote Access CPUs are required to support one core portal CPU. Thus, for this example, the total number of required CPUs would be:

  • Eight core portal CPUs

  • 16 Secure Remote Access CPUs


    • Note

    Hardware for Secure Remote Access is based on a four CPU Secure Remote Access building module, that is, the four CPU system with Sun™ Crypto Accelerator 1000 board. There are two options for core portal, a four CPU or eight CPU system.

    The building module for core Portal Server is one instance on four CPUs. Based on Secure Remote Access scalability results with this configuration, the Secure Remote Access system is one Secure Remote Access instance on four CPUs with the hardware accelerator.

    See "Working with Portal Server Building Modules" for more information on building modules.

Secure Remote Access Gateway and SSL Hardware Accelerators

SSL-intensive servers, such as the Secure Remote Access gateway, require large amounts of processing power to perform the encryption required for each secure transaction. Using a hardware accelerator in the gateway speeds up the execution of cryptographic algorithms, thereby increasing the performance speed.

The Sun Crypto Accelerator 1000 board is a short PCI board that functions as a cryptographic co-processor to accelerate public key and symmetric cryptography. This product has no external interfaces. The board communicates with the host through the internal PCI bus interface. The purpose of this board is to accelerate a variety of computationally intensive cryptographic algorithms for security protocols in ecommerce applications.

See the Sun One Portal Server, Secure Remote Access 6.0 Administration Guide for more information on the Sun Crypto Accelerator 1000 board.


Note

The Sun Crypto Accelerator 1000 board supports only SSL handshakes and not symmetric key algorithms. This is not generic to all other cryptographic accelerators. There are other cryptographic accelerators in the market and some of them can support symmetric key encryption. See the following URL for more information:

http://www.zeus.com/products/zws/security/hardware.html


You could use a hardware accelerator on the Rewriter proxy machine and derive some performance improvement, as the communication between the gateway and Rewriter proxy is HTTPS. Because the Netlet proxy does not use SSL it cannot use a hardware accelerator. The gateway does not decrypt the Netlet traffic if the Netlet proxy is enabled, but instead tunnels the Netlet requests to the Netlet proxy. Installing a hardware accelerator in the gateway or Netlet proxy does not help Netlet traffic.

About the Sun Enterprise 10000

Normally, for a production environment, you would deploy core Portal Server and Secure Remote Access on separate machines. However, in the case of the Sun Enterprise™ 10000, which supports multiple hardware domains, you can install both core Portal Server and Secure Remote Access on the same Sun Enterprise 10000 machine but in different domains. The normal CPU and memory requirements that pertain to core Portal Server and Secure Remote Access still apply; you would implement the requirements for each in the separate domains.

In this type of configuration, pay attention to security issues. For example, in most cases the Portal Server domain is located on the intranet, while the Secure Remote Access domain is in the DMZ.

Portal Sizing Tips

This section contains a few tips to help you in the sizing process.

  • A business-to-consumer portal will require that you deploy Secure Remote Access to use the gateway and SSL. Make sure you take your this into account for your sizing requirements. The rule of thumb is that once you turn on SSL, the performance of the portal can be up to ten times slower than without SSL.

  • For a business-to-employee portal, make sure that you have a user profile that serves as a baseline.

  • For any portal, build in headroom for growth. This means not just sizing for today's needs, but future needs and capacity, whether it is for usual peaks after users return from a break, such as a weekend or holiday, or if it is increased usage over time because the portal is more "sticky."

  • If you are deploying your portal solution across multiple geographic sites, you need to fully understand the layout of your networks and data centers.

  • Decide what type of redundancy you need. Consider items such as production down time, upgrades, and maintenance work. In general, when you take a portal server out of production, the impact to your capacity should be no more than one quarter (1/4) of the overall capacity.

  • In general, usage concurrencies for a business-to-employee portal are higher than a business-to-consumer portal.

Previous      Contents      Index      Next     
Copyright 2003 Sun Microsystems, Inc. All rights reserved.