|
|
|
|
| |
Planning for Capacity Requirements
The following sections provide an introduction to capacity planning for the WebLogic Server e-commerce platform:
Introduction to Capacity Planning
The BEA WebLogic Server 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. This document is meant as a guide for Capacity Planning efforts for solutions built with the WebLogic Server.
Notes: Capacity Planning is not an exact science. Every application is different and every user behavior is different. This document is intended as a guide for developing capacity planning numbers and will encourage you to err on the side of caution.
Any and all recommendations generated by this guide should be adequately verified before a given system is put into production. There is no substitute for adequately testing a prototype for capacity planning numbers.
Capacity Planning Factors to Consider
A number of factors influence how much capacity a given hardware configuration will need in order to support the WebLogic Server and a given application. 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 requirements for your configuration. Consider how much your application differs from the baseline application numbers provided in Examining Results from a Baseline Application.
What Types of Clients Connect to the WebLogic Server Application?
WebLogic Server uses T3, an optimized protocol, to transport data to other Java programs, including clients and other WebLogic Servers. WebLogic Server keeps track of every Java Virtual Machine (JVM) with which it connects, and creates a single T3 connection to carry all traffic for a JVM.
For example, if a Java client accesses an enterprise bean and a JDBC connection pool on WebLogic Server, a single network connection is established between the WebLogic Server JVM and the client JVM. The EJB and JDBC services can be written as if they had sole use of a dedicated network connection because the T3 protocol invisibly multiplexes packets on the single connection.
T3 is an efficient protocol for Java-to-Java applications because it avoids unnecessary network connection events and uses fewer OS resources. The protocol also has internal enhancements that minimize packet sizes
There are two typical types of clients that can connect to the WebLogic Server: programmatic clients (Java applications, applets, etc.) and web-based clients (web browsers, http proxies, etc.). Typically, programmatic (such as Java applications and applets) clients connect through T3 and use RMI to connect to the server. Web clients use the http protocol to get HTML or servlet output.
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. Also, the stateless nature of http:// requires that the server handle more in terms of overhead. The T3 protocol works over sockets and has a long-standing connection to the server. However, the benefits of http clients are numerous, such as ubiquity of browsers and firewall compatibility, and are usually worth the performance costs.
A WebLogic Server installation that relies only on programmatic clients should be able to handle 20% more concurrent clients than an http:// which is serving installations. If you are tunneling T3 over http, you should not see this performance benefit. In fact, performance of T3 over http is typically 15% worse than typical http and will reduce the optimum capacity of your WebLogic Server installation similarly.
What Types of Traffic Do the Clients Generate?
If you are using T3 clients, there are a number of ways that interaction with the server is accomplished. Most cases involve either RMI or events. In the case of RMI, clients typically do not generate a large amount of traffic to the server because there is only one sender and one listener. In the case of Events however, one single event with many listeners can generate a large amount of traffic for the server.
Events versus RMI changes the capacity of the server slightly depending upon the architecture of the application. In most cases, this means only that you will need to have a larger bandwidth available between clients and servers.
Does the Platform Have a WebLogic Server Performance Pack Installed?
If you install and implement a Performance Pack for your platform, you should expect a 50% increase in the number of simultaneous connections that the WebLogic Server installation can handle compared to the baseline numbers in Examining Results from a Baseline Application.
Do Clients Use SSL to Connect to the WebLogic Server?
SSL is a very intensive computing operation. Cryptography operations in the SSL protocol mean that the WebLogic Server will not be able to 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. So, SSL reduces the capacity of the server by 33-50% depending upon the strength of encryption used in the SSL connections.
Beginning with version 5.1, WebLogic Server includes native performance packs for SSL operations.
How Well-designed is the Application?
In the end, the WebLogic Server simply is a platform for user applications. Badly designed or unoptimized 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 the WebLogic Server will not be optimal and will not perform as well as benchmark applications. As a precaution, you should double the maximum capacity that you expect.
There are a number of resources available in the WebLogic Server documentation and the Customer Support centers that are available to help in designing the most efficient applications possible on WebLogic. For the latest information, please visit the WebLogic Server web sites.
The vast majority of installations find that their database server runs out of capacity much sooner that the WebLogic Server 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.
You can generally tell if your database is the bottleneck if you are unable to get the WebLogic Server CPU usage in the 85%-95% range. This is a good indication that your WebLogic Server 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.
What Else is Running on the Machine?
In many cases, the machine running the WebLogic Server is doing other things besides presentation and business logic. For example, the application may be tasked with running a Web server as well. Or, it could be charged with maintaining a remote information feed, such as a stock information feed from a quote service.
In the case in which the WebLogic Server (or the machine on which it resides) is doing substantial additional work, you need to determine how much processing power will be relegated to other processes. In the cases of a web server proxy running on the same machine as the WebLogic Server, you should expect anywhere from 25%-50% of the computing capacity to be relegated to processes that are not related to WebLogic applications compared to the baseline numbers in Examining Results from a Baseline Application.
It is important that a WebLogic Server have a large enough bandwidth to handle all of the connections from clients it is supposed to handle. 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%-150% the bandwidth that a similar web server would handle. If you are interested in the bandwidth required to run a web server, you can assume that each 56k/s 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.
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 and Solaris, you can look at what the load is on the network system. If the load is very high, bandwidth may be a bottleneck for your system.
The WebLogic Server should be tuned using the available tuning guide. If the server is not tuned, expect a 33% decrease in performance compared to the baseline numbers in Examining Results from a Baseline Application.
Is the WebLogic Server Clustered?
Clusters are much more efficient and better for failover. Customers using clustering should not see any noticeable performance degradation by doing so. A number of WebLogic deployments in production involve placing a cluster of WebLogic servers on a single multiprocessor server.
How Many Transactions Must Run Concurrently?
Analysis of this factor requires that you complete some calculations. Determine how many sessions your WebLogic Server will be expected to handle concurrently. For example, your requirement may be to have 1000 simultaneous client-server sessions. For each of these sessions, you will need to have more RAM to keep things running smoothly. Obtain as much RAM as you can. BEA Systems recommends that you install a minimum of 256 MB of memory for each WebLogic Server that will be handling more than minimal capacity.
Next, research the maximum number of clients that will make requests at the same time. In the current scenario, there are 1000 simultaneous connections. Let us project that we expect users to make new requests to the server every 20 seconds. That means, on average, the WebLogic Server will need to handle 50 operations in a second to keep up. So, it might appear that we need a machine that can do 50 transactions per second (tps).
Not exactly. You must look at the maximum number of transactions in a given period to handle spikes in demand. In this case, let us assume a surge in demand and each client is making a request every 10 seconds. That means the system must be able to handle 100 tps.
Now that you have considered factors that affect capacity, the next steps are to examine baseline results from a sample application, and to generate your own capacity planning requirements.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|