|
| |
| Sun Java System Portal Server 6 2004Q2 Deployment Planning Guide | |
Chapter 4
Pre-Deployment ConsiderationsThis chapter contains the following sections:
Determine Your Tuning GoalsBefore tuning you portal, work with portal system administrators and portal developers to set the portal performance objectives based upon the projected requirements of your portal. Objectives include the number of users, the number of concurrent users at peak load time and their usage pattern in accessing Sun Java™ System Portal Server (formerly Sun ONE Portal Server).
You need to determine these two factors:
As the number of users concurrently connected to the portal increase, the response time decreases given the same hardware and same set of parameters. Hence, gather information about the level of usage expected on your Sun Java System Portal Server, the anticipated number of concurrent users at any given time, the number of Portal desktop activity requests, the amount of portal channel usage, acceptable response time for the end-user which is determined by your organization, and an optimal hardware configuration to meet the criteria.
Portal Sizing TipsThis section contains a few tips to help you in the sizing process.
- A business-to-consumer portal will require that you deploy SRA to use the Gateway and SSL. Make sure you take this into account for your sizing requirements. 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.
Establish Performance MethodologyOnce you have established your performance goals, follow the steps below to tune your portal environment.
- Identify and remove obvious bottlenecks in the processor, memory, network, and disk.
- Setup a controlled environment to minimize the margin of error (defined as less than ten percent variation between identical runs).
It is important to know the starting data measurement baseline so that 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 will help you to uncover the origin of performance problems.
See Portal Sizing.
See Analysis Tools
Portal SizingYou need to establish a baseline sizing figure for your Portal Server. With a baseline figure established, you can then validate and refine that figure to account for scalability, high availability, reliability, and good performance.
The portal sizing process consists of the following steps:
The following sections describe these steps.
Establish Baseline Sizing Figures
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 Sun Java™ System Portal Server Secure Remote Access (SRA) software are covered in SRA Sizing.
Your Sun Java System technical representative can provide you with an automated sizing tool to calculate the estimated number of CPUs your Portal Server deployment requires. You need to gather the following metrics for input to the sizing tool:
Other performance metrics that affect the number of CPUs a Portal Server deployment requires, but are not used by the sizing tool, are:
A discussion of the these performance factors follows.
Peak Numbers
Maximum number of concurrent sessions defines how many connected users a Portal Server deployment can handle.
To calculate the maximum number of concurrent sessions, use this formula:
maximum number of concurrent sessions =
expected percent of users online * user baseTo identify the size of the 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 Portal 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.
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 hitsFor 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 Portal 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.
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:
To calculate this, use this formula:
average disk space requirement =
database size / number of RDs in databaseThe 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.
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.
Portal Desktop Configuration
Portal Desktop configuration explicitly determines the amount of data held in memory on a per-session basis.
The more channels on the Portal Desktop, the bigger data session size, and the lesser the throughput of Portal Server.
Another factor is how much interactivity the Portal 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 occur on the node that hosts the Portal Desktop than on a node that hosts some other external server.
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 also affect Portal Server performance.
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, Portal Desktop rendering and throughput request times will not be optimum. The Portal 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:
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:
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:
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.
Portal Server capacity begins to be impacted when large numbers of users log in. As more users login, they use more of the available memory, and subsequently, less memory is available to process requests made to the server. 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 Portal Desktop display is loaded. However, as more users continue to login, 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.
Customize the Baseline Sizing Figures
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. Customizing your Portal Server deployment can greatly affect its performance.
After you have an estimate of your sizing, consider:
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 begin customizing the system.
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.
Validate Baseline Sizing Figures
Now that you have an estimate of the number of CPUs for your portal deployment, use a trial deployment to measure the performance of the portal. Use load balancing and stress tests to determine:
Portal samples are provided with the Portal Server. You can use them, with channels similar to the ones you will use, to create a load on the system. The samples are located on the Portal Desktop.
Use a trial deployment to determine your final sizing estimates. A trial deployment will help you to size back-end integration, to avoid potential bottlenecks with Portal Server operations.
Refine Baseline Sizing Figures
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 SRA is covered in SRA Sizing.
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.
- Examine other factors in your deployment.
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.
- Plan for changes.
A portal site is likely to experience various changes after you launch it. Changes you might encounter include the following:
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.
The resulting figure ensures that your portal site will have:
Validate Your Final Figures
Use a trial deployment to verify that the portal deployment satisfies your business and technical requirements.
SRA SizingUse this section only if your organization is implementing a secure portal by installing SRA. As you did for portal, for SRA, you must first establish your Gateway instances baseline sizing estimate (A single machine can have one Gateway installation but multiple instances. SRA enables you to install multiple Gateways, each running multiple instances.) Your design decisions will help you make accurate estimates regarding SRA 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 SRA 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 SRA 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 Java System technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of Gateway instances your SRA deployment requires.
Identifying these key performance factors and giving them to your Sun Java System technical representative is the first step in formulating your baseline sizing figure.
These are the key performance factors:
Session Characteristics
The session characteristics of the Gateway include:
Netlet Usage Characteristics
Consider the following Netlet characteristics of the Gateway, which can have a impact in calculating the number of Gateway instances:
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.
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 user name and password. Because this process involves checking credentials, initializing the session, and delivering initial content, it is typically taxing on the system.
- 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.
For both Login Type and Desktop Type, select the appropriate content configuration:
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 SRA 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:
- 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.
SRA Gateway and SSL Hardware Accelerators
SSL-intensive servers, such as the SRA 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 e-commerce applications.
See the Portal Server Secure Remote Access 6 Administration Guide for more information on the Sun Crypto Accelerator 1000 board and other accelerators.
You could use a hardware accelerator on the Netlet Proxy and Rewriter Proxy machine and derive some performance improvement.
SRA and Sun Enterprise Midframe Line
Normally, for a production environment, you would deploy Portal Server and SRA on separate machines. However, in the case of the Sun Enterprise™ midframe machines, which support multiple hardware domains, you can install both Portal Server and SRA in different domains on the same Sun Enterprise midframe machine. The normal CPU and memory requirements that pertain to Portal Server and SRA 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 SRA domain is in the DMZ.