Skip navigation.

eDocs Home > BEA WebLogic Portal 8.1 Documentation > Capacity Planning Guide > Capacity Planning for WebLogic Portal

Capacity Planning Guide

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Capacity Planning for WebLogic Portal

This document covers the steps involved with capacity planning for WebLogic Portal 8.1 and the application of these techniques by the use of the BEA capacity planning estimation tool.

Capacity planning is not an exact science. Every application is different and every user behavior is different. This document is meant only as a guide for developing capacity planning numbers and will encourage you to err on the side of caution.

Note: Any and all recommendations provided in this guide should be adequately verified before a given system is moved into production. There is no substitute for adequately testing a prototype to obtain capacity planning numbers.

This Capacity Planning Guide contains capacity planning information for WebLogic Portal 8.1. Please contact your BEA sales representative for more information about capacity planning.

 

Introduction to Capacity Planning

BEA WebLogic Portal runs on hardware ranging from low-end PCs to high-end mainframes. The process of determining what type of hardware and software configuration is required to meet application needs adequately is called Capacity Planning.

Capacity Planning Factors to Consider

A number of factors influence how much capacity a given hardware configuration will need in order to support a WebLogic Portal and a given application. The hardware capacity required to support your application depends on the specifics of the application and configuration. You should consider how each of these factors applies to your configuration and application.

The following sections discuss several of these factors. Understanding these factors and considering the requirements of your application will aid you in generating server hardware requirements for your configuration.

For more information, see the WebLogic Server Capacity Planning Guide.

SSL Connections and Performance

Secure sockets layer (SSL) is a standard for secure Internet communications. WebLogic Server security services support X.509 digital certificates and access control lists (ACLs) to authenticate participants and manage access to network services. For example, SSL can protect JSP pages listing employee salaries, blocking access to confidential information.

SSL involves intensive computing operations. When supporting the cryptography operations in the SSL protocol, WebLogic Server cannot handle as many simultaneous connections.

You should note the number of SSL connections required out of the total number of clients required. Typically, for every SSL connection that the server can handle, it can handle three non-SSL connections. SSL reduces the capacity of the server by about 33-50% depending upon the strength of encryption used in the SSL connections. Also, the amount of overhead SSL imposes is related to how many client interactions have SSL enabled.

You can also implement SSL using hardware accelerators. Please refer to WebLogic Server documentation.

WebLogic Server Process Load

What is running on the machine in addition to a WebLogic Portal? The machine where a WebLogic Portal is running may be processing much more than presentation and business logic. For example, it could be running a web server or maintaining a remote information feed, such as a stock information feed from a quote service.

Consider how much of your WebLogic Portal machine's processing power is consumed by processes unrelated to WebLogic Portal. In the case in which the WebLogic Portal (or the machine on which it resides) is doing substantial additional work, you need to determine how much processing power will be drained by other processes.

Database Server Capacity and User Storage Requirements

Is the database a bottleneck? Are there additional user storage requirements? Many installations find that their database server runs out of capacity much sooner that the WebLogic Portal does. You must plan for a database that is sufficiently robust to handle the application. Typically, a good application will require a database that is three to four times more powerful than the application server hardware. It is good practice to use a separate machine for your database server.

Generally, you can tell if your database is the bottleneck if you are unable to maintain the WebLogic Portal CPU usage in the 80%-90% range. This is a good indication that your WebLogic Portal is spending much of its time idle and waiting for the database to return. With load balancing in a cluster, the CPU utilization across the nodes should be about even.

Some database vendors are beginning to provide capacity planning information for application servers. Frequently this is a response to the 3-tier model for applications. An application might require user storage for operations that do not interact with a database. For example, in a secure system disk and memory are required to store security information for each user. You should calculate the size required to store one user's information, and multiply by the maximum number of expected users.

Concurrent Sessions

Determine the maximum number of concurrent user sessions your WebLogic Portal will be called upon to handle. To handle more users, you will need to add more RAM for efficiency. BEA Systems recommends that you install a minimum of 256 MB of memory for each WebLogic Portal instance.

Next, research the maximum number of clients that will make requests at the same time, and how frequently each client will be making a request. The number of user interactions per second with WebLogic Portal represents the total number of interactions that should be handled per second by a given Portal deployment.

Consider also the maximum number of transactions in a given period to handle spikes in demand. For example, in a stock report application, plan for a surge after the stock market opens and before it closes. If your company is broadcasting a Web site as part of an advertisement during the World Series or World Cup Soccer playoffs, you should expect spikes in demand.

Network Load

Is the bandwidth sufficient? Network performance is affected when the supply of resources is unable to keep up with the demand. WebLogic Server requires a large enough bandwidth to handle all of the connections from clients it is to handle. If you are handling only HTTP clients, expect a similar bandwidth requirement as a web server serving static pages.

The primary factor affecting the requirements for a LAN infrastructure is the use of in-memory replication of session information. In a cluster, in-memory replication of session information is the biggest consumer of LAN bandwidth. Consider whether your application will be requiring the replication of session information.

To determine if you do not have enough bandwidth in a given deployment, you should look at the network tools provided by your network operating system vendor. In most cases, including Windows NT, Windows 2000, and Solaris, you can inspect the load on the network system. If the load is very high, bandwidth may be a bottleneck for your system.

Clustered Configurations

Is the WebLogic Portal Server configured to support clusters? Clusters provide session protection and failover via state replication. Customers using clustering should not see any noticeable performance degradation. A number of WebLogic deployments in production involve placing a cluster of WebLogic servers on a single multiprocessor server.

If you are using a web server to forward requests to a WebLogic Server cluster, sometimes the bottleneck can be the web server. This can happen when using the supplied HttpClusterServlet and a proxy server, or one of the supported plug-ins. If the response time does not improve after adding servers to the cluster and the web server machine shows a CPU usage over 95%, consider clustering the web server or running the web server on more powerful hardware.

Application Design

How well-designed is the application? Badly designed or non-optimized user applications can drastically slow down the performance of a given configuration anywhere from 10% to 50%. The best course is to assume that every application that is developed for WebLogic Portal will not be optimal and will not perform as well as benchmark applications. As a precaution, you should increase the maximum capacity that you calculate or expect.

Tuning Your WebLogic Server

Is the WebLogic Portal well-tuned? A WebLogic Server should be tuned using the available tuning guide. If the server is not tuned, expect a decrease in performance.

 

Back to Top Previous Next