Weblogic Capacity Planning

ASSESSING YOUR APPLICATION PERFORMANCE OBJECTIVES

At this stage in capacity planning, you gather information about the level of activity expected on your server, the anticipated number of users, and the number of requests, acceptable response time, and preferred hardware configuration. Capacity planning for server hardware should focus on maximum performance requirements and set measurable objectives for capacity.

The numbers that you calculate from using one of your sample applications are of course just a rough approximation of what you may see with your application. There is no substitute for benchmarking with the actual production application using production hardware. In particular, your application may reveal subtle contention or other issues not captured by our test applications.

DATABASE SERVER CAPACITY AND USER STORAGE REQUIREMENTS

First question to be verified is, whether the database a bottleneck? Are there additional user storage requirements? Often the database server runs out of capacity much sooner that Weblogic Server does. It is advisable to plan for a database that is sufficiently robust to handle the application. Typically, a good application's database requires hardware 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, database is the bottleneck if you are unable to maintain Weblogic Server CPU usage in the 85 to 95 percent range. This indicates that Weblogic Server is often idle and waiting for the database to return results. 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 three-tier model architecture for the 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.

NETWORK LOAD

Before assigning fixed bandwidth its essential to analyze whether the allocated will be sufficient enough to address your applications requests needs? Weblogic Server requires enough bandwidth to handle all connections from clients. In the case of programmatic clients, each client JVM will have a single socket to the server. Each socket requires bandwidth. A Weblogic Server handling programmatic clients should have 125 to 150 percent the bandwidth that a server with Web-based clients would handle.

If you are interested in the bandwidth required to run a web server, you can assume that each 56kbps (kilobits per second) of bandwidth can handle between seven and ten simultaneous requests depending upon the size of the content that you are delivering. 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 for servlets and stateful session EJBs. In a cluster, in-memory replication of session information is the biggest consumer of LAN bandwidth. Consider whether your application will require the replication of session information for servlets and EJBs.

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

A common definition of bandwidth is "the rate of the data communications transmission, usually measured in bits-per-second, which is the capacity of the link to send and receive communications." A machine running Weblogic Server requires enough network bandwidth to handle all Weblogic Server client connections. In the case of programmatic clients, each client JVM has a single socket to the server, and each socket requires dedicated bandwidth. A Weblogic Server instance handling programmatic clients should have 125-150 percent of the bandwidth that a similar Web server would handle. If you are handling only HTTP clients, expect a bandwidth requirement similar to a Web server serving static pages.

To determine whether you have enough bandwidth in a given deployment, you can use the network monitoring tools provided by your network operating system vendor to see what the load is on the network system. You can also use common operating system tools, such as the netstat command for Solaris or the System Monitor (perfmon) for Windows, to monitor your network utilization. If the load is very high, bandwidth may be a bottleneck for your system.

Also monitor the amount of data being transferred across your network by checking the data transferred between the application and the application server, and between the application server and the database server. This amount should not exceed your network bandwidth; otherwise, your network becomes the bottleneck. To verify this, monitor the network statistics for retransmission and duplicate packets, as follows:

Commands:

 netstat -s -P tcp

 netstat -na | grep <port> //we can grep the DB Port or MW Port also for statistics

ping response time between the machine to machine also need to consider for data transferred within the application infrastructure.

ping -s in Solaris operating environment will be useful.

ping -c in Linux operating environment uses  

CONCURRENT SESSIONS

Determine the maximum number of concurrent sessions Weblogic Server will be called upon to handle. For each session, you will need to add more RAM for efficiency. BEA/Oracle Systems recommends that you install a minimum of 256 MB of memory for each Weblogic Server installation that will be handling more than minimal capacity.  From 10g onwards, It will take minimum 1GB of memory will take.

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 Server represents the total number of interactions that should be handled per second by a given Weblogic Server deployment. Typically for Web deployments, user interactions access JSP pages or servlets. User interactions in application deployments typically access EJBs.

Consider also the maximum number of transactions in a given period to handle spikes in demand. For example, in a stock based application like www.sharekhan.com  you observe the drastic activity on the either side when the trading opens and closes.

 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 (ACL’s) to authenticate participants and manage access to network services. For example, SSL can protect JSP pages listing employee details and blocking access to confidential information w.r.t the employee or the organization.

SSL involves intensive computing operations. When supporting the cryptography operations in the SSL protocol, Weblogic Server can not handle as many simultaneous connections.

Always make a note of 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 substantially reduces the capacity of the server 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. Weblogic Server includes native performance packs for SSL operations.

It’s advisable to use third party authentication source like Siteminder instead of providing the SSL access to the required pages or modules in the site.

RMI AND SERVER TRAFFIC

It’s necessary to determine what types of server traffic do the clients generate? If you are using T3 clients, most interaction with the server, involves Remote Method Invocation (RMI.).Clients using RMI do not generate heavy traffic to the server because there is only one sender and one listener.

RMI can use HTTP tunneling to allow RMI calls to traverse a firewall. RMI tunneled through HTTP often does not deliver the higher degree of performance provided by non-tunneled RMI.

PROGRAMMATIC AND WEB-BASED CLIENTS

Primarily, two types of clients can connect to Weblogic Server:

• Web-based clients, such as Web browsers and HTTP proxies, use the HTTP or HTTPS (secure) protocol to obtain HTML or servlets output.

• Programmatic clients, such as Java applications and applets, can connect through the T3 protocol and use RMI to connect to the server.

The stateless nature of HTTP requires that the server handle more overhead than is the case with programmatic clients. However, the benefits of HTTP clients are numerous, such as the availability of browsers and firewall compatibility, and are usually worth the performance costs.

Programmatic clients are generally more efficient than HTTP clients because T3 does more of the presentation work on the client side. Programmatic clients typically call directly into EJBs while Web clients usually go through servlets. This eliminates the work the server must do for presentation. The T3 protocol operates using sockets and has a long-standing connection to the server.

A Weblogic Server installation that relies only on programmatic clients should be able to handle more concurrent clients than an HTTP proxy that is serving installations. If you are tunneling T3 over HTTP, you should not expect this performance benefit. In fact, performance of T3 over HTTP is generally 15 percent worse than typical HTTP and similarly reduces the optimum capacity of your Weblogic Server installation.

CLUSTERED CONFIGURATIONS

Clusters greatly improve efficiency and failover. Customers using clustering should not see any noticeable performance degradation. A number of Weblogic Server deployments in production involve placing a cluster of Weblogic Server instances on a single multiprocessor server.

Large clusters performing in-memory replication of session data for Enterprise JavaBeans (EJBs) or servlets require more bandwidth than smaller clusters. Consider the size of session data and the size of the cluster.

There are three general categories of traditional clustering architectures, based on how each server in the cluster accesses memory and disks, and whether servers share a copy of the operating system and the I/O subsystem. These three categories are:

• Shared-memory: In the shared-memory model, all servers in the cluster use the same primary memory, through which all traffic to the cluster is routed. The servers also share a single copy of the operating system and the I/O subsystem.

• Shared-disk: In the shared-disk model, each server has its own memory but the cluster shares common disks. Since every server can concurrently access every disk, a distributed lock manager is required.

• Shared-nothing: In the shared-nothing model, every server has its own memory and its own disks. Systems based on disk mirroring often use the shared-nothing model.

In addition, there is also the hybrid common-disk shared-nothing model, which uses a shared-nothing architecture on top of shared-disk hardware. Only one server at a time can access a disk, but if that server fails, another can provide uninterrupted service.

There are other common attributes that help define how a cluster operates.

• In an active/active cluster, each server runs its own workload, and can assume responsibility for another cluster member in the event of a failure. Commonly, this functionality means that cluster servers are paired, although it may work more generally.

• In a cluster that provides failover/failback, the workload of a failed server is automatically transferred to another server until the first server recovers, at which time its workload is automatically transferred back.

• A cluster may use IP switchover to allow clients to find the replacement for a failed server with a minimum of service disruption. IP switchover causes a replacement server to change its IP address to match that of a failed server; it requires support for DHCP (Dynamic Host Configuration Protocol) and ARP (Address Resolution Protocol) to dynamically register an IP address change and then to update the physical network address translation caches of other systems attached to the cluster subnet.

• Like switchover, IP impersonation allows clients to find a replacement server. Instead of dynamically assigning a new IP address, however, IP impersonation reroutes network traffic intended for the failed server to the replacement server.

REFERENCES

In addition to  www.oracle.com  Information on topics related to capacity planning is available from numerous third-party software sources, including the following:

Capacity Planning for Web Performance: Metrics, Models, and Methods. Prentice Hall, 1998, ISBN 0-13-693822-1 at http://www.cs.gmu.edu/~menasce/webbook/index.html

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/appc_capplan.html

Configuration and Capacity Planning for Solaris Servers, Brian Wong.

J2EE Applications and BEA Weblogic Server. Prentice Hall, 2001,

ISBN 0-13-091111-9 at http://www.phptr.com.

Web portal focusing on capacity-planning issues for enterprise application deployments at http://www.capacityplanning.com/

 -Pani