Reference By: Sarangapani Matoori
Capacity Planning
Capacity Planning
WEBLOGIC CAPACITY PLANNING :
Sample Draft
---------------------------------------------
Company : PANI Technologies
Created/Compiled by : Sarangapani Matoori
Team & Project : Pani –WS
Date of Creation : Jan 30th, 2010
Version : 1.0
Email id :sarangapani.matoori@gmail.com
updated by : ---
---------------------------------------------
TABLE OF CONTENTS
1. INTRODUCTION
2. WEBLOGIC CAPACITY PLANNING
3. CAPACITY PLANNING FACTORS
3.1 Assessing your Application Performance Objectives
3.2 Database Server Capacity and User Storage Requirements
3.3 Network Load
3.4 Concurrent Session
3.5 SSL Connection and Performance
3.6 RMI and Server Traffic
3.7 Programmatic and Web Based Clients
3.8 Clustered Configurations
4. REFERENCES
INTRODUCTION
Capacity Planning is not an exact Science but is an art of estimating the space, computer hardware, software and connection infrastructure resources that will be needed over some future period of time.
A typical capacity concern of many enterprises is whether resources will be in place to handle an increasing number of requests as the number of users or interactions increase.
The aim of the capacity planner is to plan so well that new capacity is added just in time to meet the anticipated need but not so early that resources go unused for a long period. The successful capacity planner is one that makes the trade-offs between the present and the future that overall prove to be the most cost-efficient.
The capacity planner, using business plans and forecasts, tries to imagine what the future needs will be. Analytical modeling tools can help the planner get answers to "What if" scenarios so that a range of possibilities can be explored.
The capacity planner is especially receptive to products that are seen to be scalable and also stable and predictable in terms of support and upgrades over the life of the product. As new technologies emerge and business strategies and forecasts change, capacity planners must revisit their plans.
It is usually easier to have scalability upward rather than downward since developers often must make full use of a system's resources (for example, the amount of disk storage available) when an application is initially coded. Scaling a product downward may mean trying to achieve the same results in a more constrained environment.
Every Application is different and every user behavior is different hence Capacity Planning plays a vital role.
WEBLOGIC CAPACIPY PLANNING
As per my knowledge, There are four broad areas which needs to be taken into account when planning for Weblogic based application Capacity planning.
• Capacity Planning Factors
• Assessing your Application Performance objectives.
• Hardware Tuning.
• Network Performance.
CAPACITY PLANNING FACTORS
A number of factors influence how much capacity a given hardware configuration will need in order to support a Weblogic Server instance 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.
Understanding these factors and considering the requirements of your application will aid in generating server hardware requirements for the configuration.
Capacity Planning Questions and Checkout the Link(CL)
Q) Is Weblogic Server well-tuned?
CL) Assessing Your Application Performance Objectives
Q) How well-designed is the user application?
CL) Database Server Capacity and User Storage Requirements
Q) Is the database a limiting factor? Are there additional user storage requirements?CL) Database Server Capacity and User Storage Requirements
Q) Is there enough bandwidth?
CL) Network Load
Q) What is running on the machine in addition to Weblogic Server?
CL) Network Load
Q) How many transactions need to run simultaneously?
CL) Concurrent Sessions
Q) Do clients use SSL to connect to Weblogic Server?
CL) SSL Connections and Performance
Q) What types of traffic do the clients generate?
CL) RMI and Server Traffic
Q) What types of clients connect to the Weblogic Server application?
CL)Programmatic and Web-based Clients
Q) Is your deployment configured for a cluster?
CL) Clustered Configurations
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//we can grep the DB Port or MW Port also for statistics
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.bea.com or 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
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.
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/appc_capplan.html
Web portal focusing on capacity-planning issues for enterprise application deployments at http://www.capacityplanning.com/
Regards, Sarangapani Matoori
Sr.Engineer in App Management
Sample Draft
---------------------------------------------
Company : PANI Technologies
Created/Compiled by : Sarangapani Matoori
Team & Project : Pani –WS
Date of Creation : Jan 30th, 2010
Version : 1.0
Email id :sarangapani.matoori@gmail.com
updated by : ---
---------------------------------------------
TABLE OF CONTENTS
1. INTRODUCTION
2. WEBLOGIC CAPACITY PLANNING
3. CAPACITY PLANNING FACTORS
3.1 Assessing your Application Performance Objectives
3.2 Database Server Capacity and User Storage Requirements
3.3 Network Load
3.4 Concurrent Session
3.5 SSL Connection and Performance
3.6 RMI and Server Traffic
3.7 Programmatic and Web Based Clients
3.8 Clustered Configurations
4. REFERENCES
INTRODUCTION
Capacity Planning is not an exact Science but is an art of estimating the space, computer hardware, software and connection infrastructure resources that will be needed over some future period of time.
A typical capacity concern of many enterprises is whether resources will be in place to handle an increasing number of requests as the number of users or interactions increase.
The aim of the capacity planner is to plan so well that new capacity is added just in time to meet the anticipated need but not so early that resources go unused for a long period. The successful capacity planner is one that makes the trade-offs between the present and the future that overall prove to be the most cost-efficient.
The capacity planner, using business plans and forecasts, tries to imagine what the future needs will be. Analytical modeling tools can help the planner get answers to "What if" scenarios so that a range of possibilities can be explored.
The capacity planner is especially receptive to products that are seen to be scalable and also stable and predictable in terms of support and upgrades over the life of the product. As new technologies emerge and business strategies and forecasts change, capacity planners must revisit their plans.
It is usually easier to have scalability upward rather than downward since developers often must make full use of a system's resources (for example, the amount of disk storage available) when an application is initially coded. Scaling a product downward may mean trying to achieve the same results in a more constrained environment.
Every Application is different and every user behavior is different hence Capacity Planning plays a vital role.
WEBLOGIC CAPACIPY PLANNING
As per my knowledge, There are four broad areas which needs to be taken into account when planning for Weblogic based application Capacity planning.
• Capacity Planning Factors
• Assessing your Application Performance objectives.
• Hardware Tuning.
• Network Performance.
CAPACITY PLANNING FACTORS
A number of factors influence how much capacity a given hardware configuration will need in order to support a Weblogic Server instance 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.
Understanding these factors and considering the requirements of your application will aid in generating server hardware requirements for the configuration.
Capacity Planning Questions and Checkout the Link(CL)
Q) Is Weblogic Server well-tuned?
CL) Assessing Your Application Performance Objectives
Q) How well-designed is the user application?
CL) Database Server Capacity and User Storage Requirements
Q) Is the database a limiting factor? Are there additional user storage requirements?CL) Database Server Capacity and User Storage Requirements
Q) Is there enough bandwidth?
CL) Network Load
Q) What is running on the machine in addition to Weblogic Server?
CL) Network Load
Q) How many transactions need to run simultaneously?
CL) Concurrent Sessions
Q) Do clients use SSL to connect to Weblogic Server?
CL) SSL Connections and Performance
Q) What types of traffic do the clients generate?
CL) RMI and Server Traffic
Q) What types of clients connect to the Weblogic Server application?
CL)Programmatic and Web-based Clients
Q) Is your deployment configured for a cluster?
CL) Clustered Configurations
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
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.bea.com or 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
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.
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/appc_capplan.html
Web portal focusing on capacity-planning issues for enterprise application deployments at http://www.capacityplanning.com/
Regards, Sarangapani Matoori
Sr.Engineer in App Management
THURSDAY, JANUARY 28, 2010
Performance Tuning on WebLogic Server
Tuning Weblogic Server
• Using WebLogic Server Performance Packs
Major performance improvements is seen in WebLogic Server when the performance pack is used for the application platform. Performance packs use a platform-optimized (native) socket multiplexor to improve server performance. For example, the native socket reader multiplexor threads have their own execute queue and do not borrow threads from the default execute queue, which frees up default execute threads to do application work.
To use a performance pack, make sure the Enable Native IO attribute of the Server element.
Environment>>Server (Select your server) >>Tuning>>Check the "Enable Native IO" Then Re-Start the weblogic server.
• Setting Thread Count
The value of the ThreadCount attribute of an ExecuteQueue element in the config.xml file equals the number of simultaneous operations that can be performed by applications that use the execute queue. As work enters a WebLogic Server instance, it is placed in an execute queue. This work is then assigned to a thread that does the work on it. These threads consume resources.
Note:
Performance will be degraded by increasing the value unnecessarily. By default, a new WebLogic Server instance is configured with a default execute queue (named “default”) that contains 15 threads
Thread Count Scenarios
Thread Count < number of CPUs
o This Results in an under-utilized CPU. So Increase the thread count.
Thread Count == number of CPUs
o Theoretically ideal, but the CPUs are under-utilized. So Increase the thread count.
Thread Count > number of CPUs
o Practically ideal, resulting in a moderate amount of context switching and a high CPU utilization rate.
• Assigning Applications to Execute Queues
Although the default execute queue can be configured to supply the optimal number of threads for all WebLogic Server applications, configuring multiple execute queues can provide additional control for key applications. By using multiple execute queues, we can guarantee that selected applications have access to a fixed number of execute threads, regardless of the load on WebLogic Server.
Default WebLogic Server installations are configured with a default execute queue which is used by all applications running on the server instance. You may want to configure additional queues to:
Optimize the performance of critical applications.
Throttle the performance of nonessential applications
Remedy deadlocked thread usage
To use user-defined execute queues in a WebLogic Server 9.0 domain, you need to include the use81-style-execute-queues sub-element of the server element in the config.xml file and reboot the server
myserver
true
.---
.---
• Allocating threads to act as Socket Reader
To set the maximum percentage of execute threads that read messages from a socket, the attribute ThreadPoolPercentSocketReaders should be used in the config.xml file. The optimal value for this attribute is application-specific. The default is value 33, and the valid range is 1-99. Allocating execute threads to act as socket reader threads increases the speed and the ability of the server to accept client requests.
It is essential to balance the number of execute threads that are devoted in reading messages from a socket and those threads that perform the actual execution of tasks in the server. When the native performance packs are not being used, execute threads must be allocated to act as socket reader threads.
Environment>>Server (Select your server) >>Tuning>> Specify “Socket Readers"
Then Re-Start the weblogic server.
The number of Java socket readers is computed as a percentage of the number of total execute threads (as shown in the Thread Count field for the Execute Queue).
• ConnectionPools Enhance Performance
Establishing a JDBC connection with a DBMS can be very slow. If the application requires database connections that are repeatedly opened and closed, this can become a significant performance issue. WebLogic connection pools offer an efficient solution to this problem.
When WebLogic Server starts, connections from the connection pools are opened and are available to all clients. When a client closes a connection from a connection pool, the connection is returned to the pool and becomes available for other clients; the connection itself is not closed. There is little cost to opening and closing pool connections.
• Prepared Statement Cache
The prepared statement cache keeps compiled SQL statements in memory, thus avoiding a round-trip to the database when the same statement is used later.
Set LRU from the drop down box from
Servicesà JDBC à Data Source à Connection Pool à Statement Cache Type
• Tuning JDBC ConnectionPool Initial Capacity
During development, it is convenient to set the value of the InitialCapacity attribute to a low number. This helps the server start up faster.
In production systems, consider setting InitialCapacity equal to the MaxCapacity so that all database connections are acquired during server start-up.
If InitialCapacity is less than MaxCapacity, the server then needs to create additional database connections when its load is increased. When the server is under load, all resources should be working to complete requests as fast as possible, rather than creating new database connections.
• Tuning JDBC ConnectionPool Maximum Size
The MaxCapacity attribute of the JDBCConnectionPool element allows to set the maximum number of physical database connections that a connection pool can contain. Different JDBC drivers and database servers might limit the number of possible physical connections.
In production, it is advisable that the number of connections in the pool equal the number of concurrent client sessions that require JDBC connections. The pool capacity is independent of the number of execute threads in the server. There may be many more ongoing user sessions than there are execute threads.
• Tune the chunk size
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. To reduce memory allocation costs, a server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. The default chunk size is about 4K. Use the following properties to tune the chunk size and the chunk pool size: weblogic.Chunksize—Sets the size of a chunk (in bytes).
The primary situation in which this may need to be increased is if request sizes are large. It should be set to values that are multiples of the network's maximum transfer unit (MTU), after subtracting from the value any Ethernet or TCP header sizes. Set this parameter to the same value on the client and server.
weblogic.utils.io.chunkpoolsize—Sets the maximum size of the chunk pool. The default value is 2048. The value may need to be increased if the server starts to allocate and discard chunks in steady state. To determine if the value needs to be increased, monitor the CPU profile or use a memory/ heap profiler for call stacks invoking the constructor weblogic.utils.io.Chunk.
weblogic.PartitionSize—Sets the number of pool partitions used (default is 4). The chunk pool can be a source of significant lock contention as each request to access to the pool must be synchronized. Partitioning the thread pool spreads the potential for contention over more than one partition.
• Tuning Connection Backlog Buffering
The AcceptBacklog attribute of the Server element in the config.xml file allows to set the number of connection requests the server will accept before refusing additional requests.
The AcceptBacklog attribute specifies how many TCP connections can be buffered in a wait queue. This fixed size queue is populated with requests for connections that the TCP stack has received, but the application has not accepted yet. The default value is 50 and the maximum value is operating system dependant.
Select EnvironmentàServerà Configurationà Tuning from the Administration Console to enter a value for the Accept Backlog attribute.
During operations, if many connections are dropped or refused at the client, and there are no other error messages on the server, the AcceptBacklog attribute might be set too low.
• Tuning Parameters for starting Weblogic Server
Clearly, the JVM's performance also affects WebLogic's performance. Most aspects of JVM tuning relate to the efficient management of the memory heap, an efficient garbage collection scheme, and the choice between two Unix threading models: green and native threads
The important performance tuning parameters in these files are the JAVA_HOME
parameter and the java heap size parameters:
Change the value of the variable JAVA_HOME to the location of your JDK. For
example:
set JAVA_HOME= C:\bea\jdk150_04
For higher performance throughput, set the minimum java heap size equal to the
maximum heap size. For example:
"%JAVA_HOME%\bin\java" -hotspot –ms512m –mx512m -classpath
%CLASSPATH% -
Tuning Java Virtual machines
Garbage collection is the first and foremost thing while tuning JVM. Garbage collection is the VM process of de-allocating unused java objects in the java heap.
For tuning Garbage collection we will focus on:
JVM heap size
Generational garbage collection
• JVM Heap Size
The Java heap is a repository for live objects, dead objects and free memory.
The JVM heap size determines how often and how long the VM spends collecting garbage i.e. dead objects.
Larger the heap size full garbage collection is slower and frequency is less. Smaller the heap size full garbage collection is faster and frequency is more.
• Goal for tuning heap size
To minimize the time spent doing garbage collection while maximizing number of clients to be handled at a time.
To ensure maximum performance during benchmarking the heap size values should be set in such a way that garbage collection does not occur during the entire run of the benchmark.
• Determine Optimal Heap Size
Use the -verbosegc option to turn on verbose garbage collection output for your JVM and redirect both the standard error and standard output to a log file.
Make sure that the heap size is not larger than the available free RAM on the system.
• Analyze the following data points
How often is garbage collection taking place?
In the weblogic.log file, compare the time stamps around the garbage collection.
How long is garbage collection taking?
Full garbage collection should not take longer than 3 to 5 seconds. Lower heap if major GC time is greater.
What is your average memory footprint?
In other words, what does the heap settle back down to after each full garbage collection? If the heap always settles to 85 percent free, you might set the heap size smaller.
• You might see the following Java error if you are running out of heap space
java.lang.OutOfMemoryError --no stack trace available>>
java.lang.OutOfMemoryError --no stack trace available>>
Exception in thread "main"
• Turning on Verbose Garbage Collection
Turn on verbose garbage collection output for Java VM when WebLogic Server is started, as shown in the example.
Redirect both the standard error and standard output to a log file.
This places thread dump information in the proper context with WebLogic Server informational and error messages, and provides a more useful log for diagnostic purposes.
Example
java -ms64m -mx64m -verbosegc -classpath $CLASSPATH
-Dweblogic.domain =mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==/bea/weblogic91/server/lib/weblogic.policy
-Dweblogic.management.server =192.168.0.101:7001
-Dweblogic.management.username =system
-Dweblogic.management.password =systemPassword weblogic.Server
>> logfile.txt
• Specifying Heap Size Values
Java heap size values are specified when starting the WebLogic Administration Server from the Java command line.
Example:
java ... -XX:NewSize =128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8
-Xms512m -Xmx512m
The default size for these values is measured in bytes. Append the letter ‘k’ or ‘K’ to the value to indicate kilobytes, ‘m’ or ‘M’ to indicate megabytes, and ‘g’ or ‘G’ to indicate gigabytes.
• Java Heap Size Options
-XX:NewSize:
This option is used to set the New generation Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
As a general rule, set this option to be one-fourth the size of the maximum heap size. Increase the value of this option for larger numbers of short-lived objects.
Make sure that the New generation is increased as the number of processors are increased. Memory allocation can be parallel, but garbage collection is not parallel.
-XX:MaxNewSize
This option is used to set the maximum New generation Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
-XX:SurvivorRatio
This option is used to configure the ratio of the Eden/survivor space size. Try setting this value to 8 and then monitor your garbage collection.
-Xms
This option is used to set the minimum size of the memory allocation pool. Set this value to a multiple of 1024 that is greater than 1MB. As a general rule, set minimum heap size (-Xms) equal to the maximum heap size (-Xmx).
-Xmx
This option is used to set the maximum Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
• Control Permanent Generation area size explicitly
Set initial heap size = max heap size
Permanent Generation area defaults:
o 4MB min, 32MB max
o To increase, use:
o -XX:PermSize=32m .XX:MaxPermSize=64m
Use less than ~80% available RAM on the machine
o 32-bit limit is 2GB; 64-bit is 16GB
Others
• Operating System Monitoring
Unix provides many tools for monitoring system
sar: system activity
mpstat: per-processor statistics
vmstat: virtual memory statistics
netstat: network statistics
iostat: Input/Output statistics
• EJBs
Enterprise Java Beans (EJB) are fundamentally a Java specification that allows for reuse of services. Typically, they act as bridges between the Web user and the back-end, non-Web components that make up the application.
The nature of an EJB is to be as portable and as flexible as possible so a developer need not necessarily include code to make the service transactional. Freeing the developer from concerns centered on transactional behavior, security, and lifecycle management,allows them to concentrate on implementing and improving the business logic of the application.
Making changes to applications that employ EJBs is much simpler and faster because the developer can make attribute changes, such as altering the transactional behavior without touching the business logic.
Pooling and caching are the main features that the EJB container provides to boost performance for session and entity beans. However, not all of these are applicable to all types of beans. The downside is that memory requirements are higher, though this isn't a major issue. Pooling is available for stateless session beans (SLSB), message-driven beans (MDB), and entity beans
Local Interfaces
Use local-interfaces or set call-by-reference to true to avoid the overhead of serialization when one EJB calls another or an EJB is called by a servlet/JSP in the same application. Note the following:
o In release prior to WebLogic Server 8.1, call-by-reference is turned on by default. For releases of WebLogic Server 8.1 and higher, call-by-reference is turned off by default. Older applications migrating to WebLogic Server 8.1 and higher that do not explicitly turn on call-by-reference may experience a drop in performance.
o This optimization does not apply to calls across different applications
Transaction
Avoid using the RequiresNew transaction parameter. Using RequiresNew causes the EJB container to start a new transaction after suspending any current transactions. This means additional resources, including a separate data base connection are allocated
IdleBeanCount
The number of EJBs currently idle within a pool that is managed by the Bean
Container, which provides services to EJBs, including creating bean instances, managing pools of instances, and destroying instances.
It also handles threading, transaction support, data storage, and retrieval for the beans. While a steady count of Idle Beans is normal, a climbing graph can be a strong indicator that the container needs to destroy beans at a faster rate.
A possible reason for an increased bean count is that a new application may have been deployed, or an existing one modified so that the EJBs are stateful (contain session information across session restarts; a valid application method but not always necessary). This parameter should be monitored closely for anomalous conditions.
Caching
Caching is one of the ways the WLS improves response time for the application and the end user. It places user session information in memory in the form of EJBs. These session beans containing the user’s session information are quickly and readily retrieved the next time the user visits that website.
The administrator has control over how much session information is stored in the cache and needs to be mindful of striking a balance.
From a user perspective, it would be ideal if their session information was always found in the cache, ensuring a rapid response time when they visited the website. Isn’t this the goal of IT managers?
Perhaps it is also the manager’s goal to optimize the use of WebLogic and ensure that the software is tuned to deliver the best service to all users. This means removing old session beans from the cache and properly configuring the cache size so that it does not consume too much memory of the JVM.
HTTP Sessions
In terms of pure performance, in-memory session persistence is a better overall choice when compared to JDBC-based persistence for session state.
If you use a single large attribute that contains all the session data and only 10% of that data changes, the entire attribute has to be replicated. This causes unnecessary serialization/deserialization and network overhead. You should move the 10% of the session data that changes into a separate attribute. So during developing the application need to take care the above fact.
For the cluster environment make sure that the objects which are participating in the session need to be serialized.
•Performance Terms and Definitions
Performance can be defined as: how the system’s response time and throughput are affected by adding load.
Capacity can be defined as: what the maximum threshold for the system is under a given set of conditions.
Scalability can be defined as: how well the system responds to increasing load by adding additional resources.
Most commonly we use the response time of the system and the throughput of the system as measurements for these terms.
Conclusion
The above are only some of the various ways that the server can be tuned. Bear in mind, however, that a poorly designed, poorly written application will usually have poor performance, regardless of tuning. Performance must always be a key consideration throughout the stages of the application development life cycle - from design to deployment. It happens too often that performance takes a back seat to functionality, and problems are found later that are difficult to fix.
References:
www.bea.com or
www.oracle.com
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/pdf/perform.pdf
Regards,
• Using WebLogic Server Performance Packs
Major performance improvements is seen in WebLogic Server when the performance pack is used for the application platform. Performance packs use a platform-optimized (native) socket multiplexor to improve server performance. For example, the native socket reader multiplexor threads have their own execute queue and do not borrow threads from the default execute queue, which frees up default execute threads to do application work.
To use a performance pack, make sure the Enable Native IO attribute of the Server element.
Environment>>Server (Select your server) >>Tuning>>Check the "Enable Native IO" Then Re-Start the weblogic server.
• Setting Thread Count
The value of the ThreadCount attribute of an ExecuteQueue element in the config.xml file equals the number of simultaneous operations that can be performed by applications that use the execute queue. As work enters a WebLogic Server instance, it is placed in an execute queue. This work is then assigned to a thread that does the work on it. These threads consume resources.
Note:
Performance will be degraded by increasing the value unnecessarily. By default, a new WebLogic Server instance is configured with a default execute queue (named “default”) that contains 15 threads
Thread Count Scenarios
Thread Count < number of CPUs
o This Results in an under-utilized CPU. So Increase the thread count.
Thread Count == number of CPUs
o Theoretically ideal, but the CPUs are under-utilized. So Increase the thread count.
Thread Count > number of CPUs
o Practically ideal, resulting in a moderate amount of context switching and a high CPU utilization rate.
• Assigning Applications to Execute Queues
Although the default execute queue can be configured to supply the optimal number of threads for all WebLogic Server applications, configuring multiple execute queues can provide additional control for key applications. By using multiple execute queues, we can guarantee that selected applications have access to a fixed number of execute threads, regardless of the load on WebLogic Server.
Default WebLogic Server installations are configured with a default execute queue which is used by all applications running on the server instance. You may want to configure additional queues to:
Optimize the performance of critical applications.
Throttle the performance of nonessential applications
Remedy deadlocked thread usage
To use user-defined execute queues in a WebLogic Server 9.0 domain, you need to include the use81-style-execute-queues sub-element of the server element in the config.xml file and reboot the server
.---
.---
• Allocating threads to act as Socket Reader
To set the maximum percentage of execute threads that read messages from a socket, the attribute ThreadPoolPercentSocketReaders should be used in the config.xml file. The optimal value for this attribute is application-specific. The default is value 33, and the valid range is 1-99. Allocating execute threads to act as socket reader threads increases the speed and the ability of the server to accept client requests.
It is essential to balance the number of execute threads that are devoted in reading messages from a socket and those threads that perform the actual execution of tasks in the server. When the native performance packs are not being used, execute threads must be allocated to act as socket reader threads.
Environment>>Server (Select your server) >>Tuning>> Specify “Socket Readers"
Then Re-Start the weblogic server.
The number of Java socket readers is computed as a percentage of the number of total execute threads (as shown in the Thread Count field for the Execute Queue).
• ConnectionPools Enhance Performance
Establishing a JDBC connection with a DBMS can be very slow. If the application requires database connections that are repeatedly opened and closed, this can become a significant performance issue. WebLogic connection pools offer an efficient solution to this problem.
When WebLogic Server starts, connections from the connection pools are opened and are available to all clients. When a client closes a connection from a connection pool, the connection is returned to the pool and becomes available for other clients; the connection itself is not closed. There is little cost to opening and closing pool connections.
• Prepared Statement Cache
The prepared statement cache keeps compiled SQL statements in memory, thus avoiding a round-trip to the database when the same statement is used later.
Set LRU from the drop down box from
Servicesà JDBC à Data Source à Connection Pool à Statement Cache Type
• Tuning JDBC ConnectionPool Initial Capacity
During development, it is convenient to set the value of the InitialCapacity attribute to a low number. This helps the server start up faster.
In production systems, consider setting InitialCapacity equal to the MaxCapacity so that all database connections are acquired during server start-up.
If InitialCapacity is less than MaxCapacity, the server then needs to create additional database connections when its load is increased. When the server is under load, all resources should be working to complete requests as fast as possible, rather than creating new database connections.
• Tuning JDBC ConnectionPool Maximum Size
The MaxCapacity attribute of the JDBCConnectionPool element allows to set the maximum number of physical database connections that a connection pool can contain. Different JDBC drivers and database servers might limit the number of possible physical connections.
In production, it is advisable that the number of connections in the pool equal the number of concurrent client sessions that require JDBC connections. The pool capacity is independent of the number of execute threads in the server. There may be many more ongoing user sessions than there are execute threads.
• Tune the chunk size
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. To reduce memory allocation costs, a server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. The default chunk size is about 4K. Use the following properties to tune the chunk size and the chunk pool size: weblogic.Chunksize—Sets the size of a chunk (in bytes).
The primary situation in which this may need to be increased is if request sizes are large. It should be set to values that are multiples of the network's maximum transfer unit (MTU), after subtracting from the value any Ethernet or TCP header sizes. Set this parameter to the same value on the client and server.
weblogic.utils.io.chunkpoolsize—Sets the maximum size of the chunk pool. The default value is 2048. The value may need to be increased if the server starts to allocate and discard chunks in steady state. To determine if the value needs to be increased, monitor the CPU profile or use a memory/ heap profiler for call stacks invoking the constructor weblogic.utils.io.Chunk.
weblogic.PartitionSize—Sets the number of pool partitions used (default is 4). The chunk pool can be a source of significant lock contention as each request to access to the pool must be synchronized. Partitioning the thread pool spreads the potential for contention over more than one partition.
• Tuning Connection Backlog Buffering
The AcceptBacklog attribute of the Server element in the config.xml file allows to set the number of connection requests the server will accept before refusing additional requests.
The AcceptBacklog attribute specifies how many TCP connections can be buffered in a wait queue. This fixed size queue is populated with requests for connections that the TCP stack has received, but the application has not accepted yet. The default value is 50 and the maximum value is operating system dependant.
Select EnvironmentàServerà Configurationà Tuning from the Administration Console to enter a value for the Accept Backlog attribute.
During operations, if many connections are dropped or refused at the client, and there are no other error messages on the server, the AcceptBacklog attribute might be set too low.
• Tuning Parameters for starting Weblogic Server
Clearly, the JVM's performance also affects WebLogic's performance. Most aspects of JVM tuning relate to the efficient management of the memory heap, an efficient garbage collection scheme, and the choice between two Unix threading models: green and native threads
The important performance tuning parameters in these files are the JAVA_HOME
parameter and the java heap size parameters:
Change the value of the variable JAVA_HOME to the location of your JDK. For
example:
set JAVA_HOME= C:\bea\jdk150_04
For higher performance throughput, set the minimum java heap size equal to the
maximum heap size. For example:
"%JAVA_HOME%\bin\java" -hotspot –ms512m –mx512m -classpath
%CLASSPATH% -
Tuning Java Virtual machines
Garbage collection is the first and foremost thing while tuning JVM. Garbage collection is the VM process of de-allocating unused java objects in the java heap.
For tuning Garbage collection we will focus on:
JVM heap size
Generational garbage collection
• JVM Heap Size
The Java heap is a repository for live objects, dead objects and free memory.
The JVM heap size determines how often and how long the VM spends collecting garbage i.e. dead objects.
Larger the heap size full garbage collection is slower and frequency is less. Smaller the heap size full garbage collection is faster and frequency is more.
• Goal for tuning heap size
To minimize the time spent doing garbage collection while maximizing number of clients to be handled at a time.
To ensure maximum performance during benchmarking the heap size values should be set in such a way that garbage collection does not occur during the entire run of the benchmark.
• Determine Optimal Heap Size
Use the -verbosegc option to turn on verbose garbage collection output for your JVM and redirect both the standard error and standard output to a log file.
Make sure that the heap size is not larger than the available free RAM on the system.
• Analyze the following data points
How often is garbage collection taking place?
In the weblogic.log file, compare the time stamps around the garbage collection.
How long is garbage collection taking?
Full garbage collection should not take longer than 3 to 5 seconds. Lower heap if major GC time is greater.
What is your average memory footprint?
In other words, what does the heap settle back down to after each full garbage collection? If the heap always settles to 85 percent free, you might set the heap size smaller.
• You might see the following Java error if you are running out of heap space
java.lang.OutOfMemoryError --no stack trace available>>
java.lang.OutOfMemoryError --no stack trace available>>
Exception in thread "main"
• Turning on Verbose Garbage Collection
Turn on verbose garbage collection output for Java VM when WebLogic Server is started, as shown in the example.
Redirect both the standard error and standard output to a log file.
This places thread dump information in the proper context with WebLogic Server informational and error messages, and provides a more useful log for diagnostic purposes.
Example
java -ms64m -mx64m -verbosegc -classpath $CLASSPATH
-Dweblogic.domain =mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==/bea/weblogic91/server/lib/weblogic.policy
-Dweblogic.management.server =192.168.0.101:7001
-Dweblogic.management.username =system
-Dweblogic.management.password =systemPassword weblogic.Server
>> logfile.txt
• Specifying Heap Size Values
Java heap size values are specified when starting the WebLogic Administration Server from the Java command line.
Example:
java ... -XX:NewSize =128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8
-Xms512m -Xmx512m
The default size for these values is measured in bytes. Append the letter ‘k’ or ‘K’ to the value to indicate kilobytes, ‘m’ or ‘M’ to indicate megabytes, and ‘g’ or ‘G’ to indicate gigabytes.
• Java Heap Size Options
-XX:NewSize:
This option is used to set the New generation Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
As a general rule, set this option to be one-fourth the size of the maximum heap size. Increase the value of this option for larger numbers of short-lived objects.
Make sure that the New generation is increased as the number of processors are increased. Memory allocation can be parallel, but garbage collection is not parallel.
-XX:MaxNewSize
This option is used to set the maximum New generation Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
-XX:SurvivorRatio
This option is used to configure the ratio of the Eden/survivor space size. Try setting this value to 8 and then monitor your garbage collection.
-Xms
This option is used to set the minimum size of the memory allocation pool. Set this value to a multiple of 1024 that is greater than 1MB. As a general rule, set minimum heap size (-Xms) equal to the maximum heap size (-Xmx).
-Xmx
This option is used to set the maximum Java heap size. Set this value to a multiple of 1024 that is greater than 1MB.
• Control Permanent Generation area size explicitly
Set initial heap size = max heap size
Permanent Generation area defaults:
o 4MB min, 32MB max
o To increase, use:
o -XX:PermSize=32m .XX:MaxPermSize=64m
Use less than ~80% available RAM on the machine
o 32-bit limit is 2GB; 64-bit is 16GB
Others
• Operating System Monitoring
Unix provides many tools for monitoring system
sar: system activity
mpstat: per-processor statistics
vmstat: virtual memory statistics
netstat: network statistics
iostat: Input/Output statistics
• EJBs
Enterprise Java Beans (EJB) are fundamentally a Java specification that allows for reuse of services. Typically, they act as bridges between the Web user and the back-end, non-Web components that make up the application.
The nature of an EJB is to be as portable and as flexible as possible so a developer need not necessarily include code to make the service transactional. Freeing the developer from concerns centered on transactional behavior, security, and lifecycle management,allows them to concentrate on implementing and improving the business logic of the application.
Making changes to applications that employ EJBs is much simpler and faster because the developer can make attribute changes, such as altering the transactional behavior without touching the business logic.
Pooling and caching are the main features that the EJB container provides to boost performance for session and entity beans. However, not all of these are applicable to all types of beans. The downside is that memory requirements are higher, though this isn't a major issue. Pooling is available for stateless session beans (SLSB), message-driven beans (MDB), and entity beans
Local Interfaces
Use local-interfaces or set call-by-reference to true to avoid the overhead of serialization when one EJB calls another or an EJB is called by a servlet/JSP in the same application. Note the following:
o In release prior to WebLogic Server 8.1, call-by-reference is turned on by default. For releases of WebLogic Server 8.1 and higher, call-by-reference is turned off by default. Older applications migrating to WebLogic Server 8.1 and higher that do not explicitly turn on call-by-reference may experience a drop in performance.
o This optimization does not apply to calls across different applications
Transaction
Avoid using the RequiresNew transaction parameter. Using RequiresNew causes the EJB container to start a new transaction after suspending any current transactions. This means additional resources, including a separate data base connection are allocated
IdleBeanCount
The number of EJBs currently idle within a pool that is managed by the Bean
Container, which provides services to EJBs, including creating bean instances, managing pools of instances, and destroying instances.
It also handles threading, transaction support, data storage, and retrieval for the beans. While a steady count of Idle Beans is normal, a climbing graph can be a strong indicator that the container needs to destroy beans at a faster rate.
A possible reason for an increased bean count is that a new application may have been deployed, or an existing one modified so that the EJBs are stateful (contain session information across session restarts; a valid application method but not always necessary). This parameter should be monitored closely for anomalous conditions.
Caching
Caching is one of the ways the WLS improves response time for the application and the end user. It places user session information in memory in the form of EJBs. These session beans containing the user’s session information are quickly and readily retrieved the next time the user visits that website.
The administrator has control over how much session information is stored in the cache and needs to be mindful of striking a balance.
From a user perspective, it would be ideal if their session information was always found in the cache, ensuring a rapid response time when they visited the website. Isn’t this the goal of IT managers?
Perhaps it is also the manager’s goal to optimize the use of WebLogic and ensure that the software is tuned to deliver the best service to all users. This means removing old session beans from the cache and properly configuring the cache size so that it does not consume too much memory of the JVM.
HTTP Sessions
In terms of pure performance, in-memory session persistence is a better overall choice when compared to JDBC-based persistence for session state.
If you use a single large attribute that contains all the session data and only 10% of that data changes, the entire attribute has to be replicated. This causes unnecessary serialization/deserialization and network overhead. You should move the 10% of the session data that changes into a separate attribute. So during developing the application need to take care the above fact.
For the cluster environment make sure that the objects which are participating in the session need to be serialized.
•Performance Terms and Definitions
Performance can be defined as: how the system’s response time and throughput are affected by adding load.
Capacity can be defined as: what the maximum threshold for the system is under a given set of conditions.
Scalability can be defined as: how well the system responds to increasing load by adding additional resources.
Most commonly we use the response time of the system and the throughput of the system as measurements for these terms.
Conclusion
The above are only some of the various ways that the server can be tuned. Bear in mind, however, that a poorly designed, poorly written application will usually have poor performance, regardless of tuning. Performance must always be a key consideration throughout the stages of the application development life cycle - from design to deployment. It happens too often that performance takes a back seat to functionality, and problems are found later that are difficult to fix.
References:
www.bea.com or
www.oracle.com
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/pdf/perform.pdf
Regards,
Sarangapani Matoori
Sr.Engineer in App Management
Sr.Engineer in App Management
No comments:
Post a Comment