Professional Documents
Culture Documents
D83171GC10 - SG - Oracle WebLogic Server 12c - Performance Tuning Workshop (Student Guide)
D83171GC10 - SG - Oracle WebLogic Server 12c - Performance Tuning Workshop (Student Guide)
Student Guide
D83171GC10
Edition 1.0
January 2014
D85092
Authors Copyright © 2014
, Oracle and/or its affiliates. All rights reserved.
Mark Lindros This document contains proprietary information and is protected by copyright and
other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
Technical Contributors in any way. Except where your use constitutes "fair use" under copyright law, you
and Reviewers may not use, share, download, upload, copy, print, display, perform, reproduce,
publish, license, post, transmit, or distribute this document in whole or in part without
TJ Palazzolo the express authorization of Oracle.
Bill Bell
The information contained in this document is subject to change without notice. If you
Mathew Slingsby find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
Serge Moiseev warranted to be error-free.
Kevin Tate
Takyiu Liu Restricted Rights Notice
Jose Alvarez If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is
Ahmed Gaid applicable:
Colin Stevenson
U.S. GOVERNMENT RIGHTS
David Anderson The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Mark Scarton license agreement and/or the applicable U.S. Government contract.
Mike Williams
Trademark Notice
Diganta Choudhury
Eric Gross Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Editors
Malavika Jinka
Aju Kumar
Graphic Designer
Seema Bopaiah
Publishers
Sumesh Koshy
Giri Venugopal
Contents
1 Course Introduction
Course Objectives 1-2
Target Audience 1-3
Course Prerequisites 1-4
Introductions and Setting Expectations 1-5
Course Schedule 1-6
Course Practices 1-8
Classroom Guidelines 1-9
Facilities in Your Location 1-10
For More Information 1-11
Related Training 1-12
iii
Practice 2-2 Overview: Exploring the Course Applications 2-25
Agenda 2-26
Load-Testing Tools 2-27
Choosing Testing Tools 2-28
The Grinder 2-29
The Grinder Architecture 2-30
The Grinder Console 2-32
The Grinder Summary Statistics 2-33
Monitoring Performanceby Using the Administration Console 2-34
iv
Agenda 3-34
File Handles 3-35
TCP/IP Parameters to Support a Large Number of Connections 3-36
Section Summary 3-39
Practice 3-4 Overview: Analyzing and Tuning Linux Kernel Parameters 3-40
Agenda 4-4
What Is Performance? 4-5
Performance Focus for This Lesson 4-7
HotSpot JVM Monitoring Tools 4-8
Section Summary 4-9
Agenda 4-10
Garbage Collection Basics 4-11
Generational Garbage Collection 4-12
Garbage Collectors: Java Heap Options 4-14
Setting Heap Memory Size 4-15
Setting Heap Size Options 4-16
G1 Garbage Collector 4-18
GC Algorithms 4-20
GC Performance Goals 4-22
v
Practice 4-2 Overview: Using JVM Command Line Tools 4-45
Agenda 4-46
Java Monitoring and Management Architecture 4-47
Java VisualVM 4-48
Java VisualVM Connections 4-49
Remote Monitoring 4-50
Java VisualVM Interface 4-51
Monitoring JVM 4-52
Monitoring Threads 4-53
vi
Flight Recorder Memory: Object Statistics 4-86
Section Summary 4-87
Practice 4-6 Overview: Using Flight Recorder 4-88
vii
Architecture Advantages and Disadvantages 6-10
Cluster Communication 6-12
Section Summary 6-14
Practice 6-1 Overview: Configuring Multicast and Unicast Clustering 6-15
Agenda 6-16
A Cluster Proxy for a Web Application Cluster 6-17
Proxy Plug-Ins 6-18
Oracle HTTP Server (OHS) 6-19
Hardware Load Balancers 6-21
Agenda 7-3
Connection Pools 7-4
Connection Pool Sizing 7-5
Database Listener Timeouts 7-7
JDBC and Application Design 7-8
Section Summary 7-9
Agenda 7-10
Connection Testing 7-11
Shrink Frequency 7-13
Section Summary 7-14
Practice 7-1 Overview: Tuning JDBC Connection Pools 7-15
Agenda 7-16
Row Prefetch 7-17
Statement Caching 7-18
viii
Practice 7-3 Overview: Testing Performance of Pinned to Thread 7-24
Practice 7-4 Overview: Configuring Batch Updates 7-25
Agenda 7-26
Combining Transactions 7-27
Batch Updates 7-28
Transaction Isolation Levels 7-29
Operations Permitted at Each Isolation Level 7-30
Transaction Isolation Levels 7-31
Section Summary 7-32
Agenda 7-33
Exalogic Optimizations 7-34
Section Summary 7-35
Agenda 7-36
Oracle Database Tuning 7-37
Section Summary 7-40
Practice 7-5 Overview: Tuning an Oracle Database for WebLogic 7-41
ix
Tuning JSP: Compilation Tuning 9-10
HttpSession Replication Tuning 9-11
keepgenerated Parameter 9-12
Page Check Interval 9-13
verbose Parameter 9-15
Servlet Reload Check Interval 9-16
Using Web Servers for Static Content 9-17
Session Timeout 9-18
Session Invalidation 9-19
x
Course Introduction
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Course Objectives
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
In addition to these high-level terminal objectives, each lesson has a lower-level set of enabling
objectives.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
If you are concerned whether your background and experience match that of the target
audience, ask the instructor.
Required
• Learners should have completed D80149GC10 Oracle
WebLogic Server 12c: Administration I or have equivalent
experience.
Suggested
• System administration experience
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Introduce yourself:
• Name
• Your company and role
• Your experience with WebLogic Server 12c and/or prior
releases
• Anything specific you are looking for in this class
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Have everybody say a little about themselves and what they want from this course. This is a
great time to set student expectations as to what they will or will not experience in this course.
It is also a great way for instructors to know which topics are of the most interest to their
students.
Day One
1. Course Introduction
2. Performance Tuning Methodology
3. Tuning Operating System Resources
4. Tuning HotSpot JVM
Day Two
5. Monitor and Tune Server Performance
6. Monitor and Tune Cluster Performance
7. Tuning JDBC Performance
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Day Three
8. Configuring Work Managers
9. Monitoring and Tuning Java EE Applications
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
These guidelines enable you to get maximum benefit from the course.
• Enrollment/Registration/Sign in
• Badges
• Parking
• Phones
• Internet
• Restrooms
• Labs
• Lunch
• Kitchen/Snacks
• Hours
• Materials (paper, pens, and markers)
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Contact your instructor or the education coordinator for site-specific information. This may not
be applicable for a Live Virtual Class (LVC).
Topic Website
Education and training http://education.oracle.com
Product documentation http://www.oracle.com/technology/documentation
Product downloads http://www.oracle.com/technology/software
Product articles http://www.oracle.com/technology/pub/articles
Product support http://www.oracle.com/support
Product forums http://forums.oracle.com
Oracle Learning Library
http://www.oracle.com/oll
Product tutorials and demos
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
These materials are not intended to be a complete reference for all W ebLogic Server
performance tuning topics and features. After you complete the course, Oracle offers a variety
of resources that you can use to obtain additional information.
Course Title
Oracle WebLogic Server: Administration I
Oracle WebLogic Server: Administration II
Oracle WebLogic Server: JMS Administration
Oracle WebLogic Server: Troubleshooting Workshop
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Note that some of the courses listed in the slide may be available as traditional or virtual
classroom training, whereas others may be self-paced, online offerings.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Objectives
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Concept Description
Response time A time metric (for example, the time it takes the server to
deliver a web page)
Latency The time between the issuing of a request and the actual work
beginning on that request (Often latency is intertwined with
response time.)
Throughput A rate metric (requests per unit of time) (for example, requests
per second, bytes (B/KB/MB) per second)
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The performance of a system is measured mainly in terms of the response time, throughput per
unit time, and the resource utilization. However, in multitier systems that use the W ebLogic
Server implementations, the term “latency” often occurs in discussions about response time.
Latency refers to the time between the issuing of a request and the time when the work actually
begins on the request. For example, when a browser issues an HTTP request, it takes some
time for the request to arrive at the target server, and for the target server to start work on the
request. That time spent in transit (while no work is being done on the request) is latency.
Naturally, you will want to reduce the latency, improve the response time, increase the
throughput, and optimize the resource utilization of the system.
• Hardware expansion
ci
• Resource contention tr
e
M
e
c
n
a
rm
o
rf
e
P
Increasing Resource
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The scalability of the system is related to the ability of the system to accommodate increasing
load without having the system degrading unacceptably in performance.
For more information about the concepts on scalability and configuration information for
WebLogic Server, refer to Oracle® Fusion Middleware Performance and Tuning Guide 12c
Release 1 (12.1.2).
The chart in this slide shows the scalability of two different tests. Perhaps Test A is before
tuning and Test B is after tuning. The chart represents any possible scenario whereby
something increases that affects scalability, and some performance metric is captured to see if
scalability is achieved. Test A clearly shows a decline in performance as the resource is
increased, while Test B shows linear, increased performance.
Soak Test A stress test or load test that is run for a long period of time
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Functional testing verifies that an application demonstrates the correct behavior under certain
inputs. Load testing determines whether an application can support a specified load (for
example, 500 concurrent users) with specified response times. Load testing is used to create
benchmarks. Soak testing is load testing over an extended period of time. Soak testing
determines whether an application can meet specified goals for stability and reliability, under a
specified load, for a specified time period.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
There are certain considerations to keep in mind when undergoing performance testing. The
purpose of a performance test is to determine how the system performs in the actual conditions
within which it will run. Generating the client load on the system using the same hardware
skews the numbers because resource utilization is affected by the processing required to
generate the load. Similarly, if your profiling software is too intrusive or heavy, it can also skew
the numbers because resource utilization is affected again. Java applications, which include
Java application servers, interpret, compile, and optimize Java bytecode when the process is
started initially. The most accurate performance numbers are achieved by giving the JVM and
WebLogic ample time to “warm up” to a steady state before attempting to do your performance
testing. Otherwise, the performance numbers you collect may be skewed again because the
system was not fully optimized or was still spawning threads and performing other initialization
work.
The testing environment and the production environment should be identical in every way
possible. Many companies save money by using scaled-down systems for testing, but lose that
money right back in production because they run into unforeseen problems. A scaled-down
system might become CPU-bound during stress testing, but perhaps the larger production
system is more likely to become disk I/O bound. It is worth the investment and relief of stress
that comes when production is down.
A benchmark:
• Is a performance measurement of a system
• Is used to compare system performance in different
circumstances
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
To determine your performance objectives, you must understand the application deployed and
the environmental constraints placed on the system. Gather information about the levels of
activity that components of the application are expected to meet, such as:
• The anticipated number of users
• The number and size of requests
• The amount of data and its consistency
• Your target CPU utilization
Performance objectives are limited by constraints, such as the configuration of hardware and
software, including CPU type, disk size versus disk speed, and memory. There is no single
formula for determining your hardware requirements. The process of determining what type of
hardware and software configuration is required to meet application needs adequately is called
capacity planning. Capacity planning requires assessment of your system performance goals
and an understanding of your application. Capacity planning for server hardware should focus
on maximum performance requirements. In addition, consider how much of your WebLogic
Server machine’s processing power is consumed by processes unrelated to WebLogic Server.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
You begin a stress testing plan by testing the use cases of the application. Because those use
cases provide a description of how the application is used when in production. Use cases can
often be translated directly into test scripts that can be run against the application.
Three very useful and free tools that you can use to start generating client load to stress a
WebLogic application are:
• The Grinder (http://sourceforge.net/projects/grinder), which is an all Java tool that is
customizable via plug-in modules
• Apache JMeter (http://jakarta.apache.org/jmeter/), which is an open source all Java
software designed to load test functional behavior and measure performance
The stress tests should include micro benchmarks, that is, tests on small parts of the
application. The parts of an application that are used the most should be tested on their own.
That way, if you can tune those parts, your performance will increase quite a bit. Even though
testing the most used parts of an application is important, it does not replace stress testing the
whole application (including database access).
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
In a customer satisfaction survey, a direct correlation was shown between the amount of
testing performed and the customer’s satisfaction with the application.
In every measure including overall product effectiveness, reliability, speed, and scalability,
customers that did more testing and more formalized testing had better results than those that
did not test.
Select parameters
What is the
workload to place
Define Modify to change and
apply one at a
on the system? Workload Settings
time.
Done
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Whatever is being tested should match the ultimate deployment environment. Failure to do so
could skew performance results and put you in a difficult position in production. This slide
shows some examples of things that can go wrong or things to keep in mind.
forced to do so.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The performance of an application can be affected by factors such as the application code, the
operating system, the hardware platform, and more. Therefore, benchmark results should be
reported with, at least, the following information:
• A detailed description of the application, such as a class diagram and/or use case
diagram
• The type of operating system, including version and patch level
• The version and patch level of WebLogic Server
• The details about the hardware, such as the processor speed, hard drive space, and the
amount of RAM
• The performance characteristics of any external systems
Without providing details about the environment, the benchmark results have little meaning.
Benchmarks given in the wrong context can cause uncertainty and doubt.
The benchmark results are appropriate for the application in the specific test environment. It
should not be assumed that the application would exhibit the same behavior when put into a
different environment. The volume of performance test result data can mount quickly. Consider
using a relational database for storing and analyzing test result data.
Number Avg.
Client Avg. Configuration
of App. Resp.
Load Throughput ID
Servers Time
1 2128ms 2000 100TPS small_clust03
Analysis: Scalability of a
software system
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Archiving test result data in a relational database can help you observe long-term trends and
establish reliable baseline data, especially when compared to “live” statistics collected after the
application is deployed and operational. Many commercial performance-testing tools use a
relational database for storing test result data because of these advantages. Also, consider
archiving the version of W ebLogic Server, OS, hardware, network, and other configuration data
along with the application-specific metrics you collect.
The performance-reporting tools also enable you to provide an identifier for each test run to
enable easier comparison.
The table in the slide shows the benchmark results based on the number of application
servers.
CPU Bound The system cannot process additional workload because the
processor is too busy (at or near 100%).
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Generally, your goal is to get to a point where the application server achieves your target CPU
utilization. If you find that the application server CPU is underutilized, confirm whether the
database is bottlenecked. If the database CPU is 100% used, check the query plans of SQL
calls in your application. For example, are your SQL calls using indexes or doing linear
searches? Also, confirm whether there are too many ORDER BY clauses used in your
application that are affecting the database CPU. If you discover that the database disk is the
bottleneck (for example, if the disk is 100% used), try moving to faster disks or to a redundant
array of independent disks (RAID) configuration, assuming the application is not doing more
writes than required.
When you know that the database server is not the bottleneck, determine whether the
application server disk is the bottleneck. The disk I/O on an application server can be optimized
using faster disks or RAID, disabling synchronous Java Message Service (JMS) writes, using
Java Transaction API (JTA) direct writes for transaction logs, or increasing the HTTP log
buffer.
Check the amount of 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.
PossibleCauses Solutions
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Ideally, the CPU should run only at 50%–75%, although there are some applications where
having the CPU running near 85%–95% is fine. After the CPU is bound, the application server
cannot do any more work. Adding threads will not do anything because the CPU is doing its
maximum amount of work. In some cases, the problem may even be caused by allocating too
many threads.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
I/O bound is very common in real-world applications. This is a situation in which the CPUs are
not saturated, but the performance is the same regardless of the number of clients. For
example, 10 clients send 50 transactions per second to the database, but if there are only five
clients, they still send 50 transactions per second to the database. In this scenario, usually the
requests from clients may be waiting for I/O operations, and the performance bottlenecks could
also be the disk, network, or database.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
When the disk is overrun, something on the machine is over-utilizing it. This means that it is not
necessarily the application, although it could be. Common causes of disk bound issues are
excessive logging or if physical memory is insufficient to run everything all at once. First, verify
if virtual memory is in use. If it is, then you either have a memory leak in your application, your
application is not sized correctly, or the amount of physical memory on the system is too low. If
virtual memory is not in use, then you have to profile the system to find the offending processes
that are using the disk and profile those processes for offending operations.
PossibleCauses Solutions
Network bandwidth is not used efficiently Use larger packets, which make better
use of network bandwidth.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The network can be your bottleneck if it gets saturated, which is common over W AN links
because there is not much bandwidth. Monitor your network to determine how much bandwidth
is being used. The easiest fix is to buy more bandwidth. You can use a network sniffing tool to
monitor and analyze network performance issues.
PossibleCauses Solutions
Too fewfor
waiting connections so clients are
a connection Create more database connections.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
When the database is the bottleneck, there are many solutions, depending on the cause of the
problem. Sometimes, the number of connections is too low, and concurrent clients block,
waiting for a connection to free up. Then the solution is to create and use more database
connections. Sometimes, queries take too much time. In this case, the solution may be to
create secondary indexes on certain fields. If your database server’s machine is too slow, look
for better hardware, or move the database to a dedicated machine. If these solutions do not
resolve the problem, look into the fine-tuning options for your vendor-specific database.
Many of the solutions for handling a database bottleneck reside with application programmers.
Programmers can make more efficient trips to the database by grabbing all their information in
one query instead of multiple queries. This topic goes beyond the scope of this course.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
• Apache JMeter
• HP LoadRunner
• RadView WebLOAD
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
JMeter is an Apache Jakarta project that can be used as a load-testing tool for analyzing and
measuring the performance of a variety of services, with a focus on web applications. JMeter
can be used as a unit-test tool for Java Database Connectivity (JDBC) database connections,
FTP, Lightweight Directory Access Protocol (LDAP), web services, JMS, HTTP, and generic
TCP connections. JMeter also supports assertions to ensure that the data received is correct,
per-thread cookies, configuration variables, and a variety of reports.
LoadRunner is a performance- and load-testing product by Hewlett-Packard (since it acquired
Mercury Interactive in November 2006) for examining system behavior and performance, while
generating actual load. Working in LoadRunner involves using three different tools, which are
part of LoadRunner. They are Virtual User Generator (VuGen), Controller, and Analysis.
• Reporting
• Accuracy of results
• Cost
• Learning
• Other features
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
You mainly consider the hardware and software resources in your environment and choose
suitable testing tools. You should also consider the knowledge of the personnel in your
organization, and the cost of training if required.
In this course, you use The Grinder, which is developed in Java and released under the
Berkeley Software Distribution (BSD) license (open source).
• The Grinder:
– Is a load-testing tool
– Is an open-source implementation based on Java and
Python
– Supports a distributed, agent-based load-simulation model
– Provides a graphical console to manage agents and view
aggregated results
– Supports HTTP/S (links, forms, cookies, and so on) but can
be extended to support additional protocols
• The Grinder agent:
– Utilizes a specific number of processes and threads
– Executes a supplied test script with each thread
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The Grinder is a Java load-testing framework that makes it easy to run a distributed test using
many load-injector machines. It is freely available under a BSD-style open-source license, and
is based on other open-source technologies such as Jython, HTTPClient, XMLBeans, and
PicoContainer. The Grinder was srcinally developed for the book Professional Java 2
Enterprise Edition with BEA WebLogic Server.
Each test context runs in its own thread. The threads can be split over many processes
depending on the requirements of the test and the capabilities of the load-injection machine.
The Grinder makes it easy to coordinate and monitor the activity of processes across a network
of many load-injection machines from a central console.
Scripts can be created by recording actions of a real user by using TCPProxy. The script can
then be customized manually. Input data (for example, URL parameters or form fields) can be
dynamically generated. The source of the data can be anything including flat files, random
generation, a database, or previously captured output.
CPU
Agent
Start test
Thread
Thread
1 Report results 3 Thread 2
HTTP/S System
Console
CPU under test
1 3 Agent
Thread
Thread
Thread 2
Test script
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The Grinder has a framework for running test scripts across a number of machines. The
framework comprises three types of processes:
• Worker processes interpret Jython test scripts and perform tests using a number of
worker threads.
• Agent processes manage worker processes.
• The console coordinates the other processes, and collates and displays resulting
statistics.
Because The Grinder is written in Java, each of these processes is a Java Virtual Machine.
For heavy-duty testing, you start an agent process on each of the load-injector machines. The
worker processes that they start can be controlled and monitored using the console. There is
little reason to run more than one agent on each load injector, but you can if you want. Each
worker process sets up a network connection to the console to report statistics. Each agent
process sets up a connection to the console to receive commands, which it passes on to its
worker processes. The console listens for both types of connection on a particular address and
port.
Results for
individual requests
Overall results
for an entire
test
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
The Start processes, Reset processes, and Stop processes menu items send signals to The
Grinder processes that are listening. These controls are disabled if no agents are connected to
the console. On the Processes tab, you can check whether any agents are connected. The
Start processes send signals to worker processes that they should move into the running state.
Processes that are already running ignore this signal. Processes that are in the finished state
exit. The agent process then rereads the properties file and launches new worker processes in
the running state. The Reset processes signal all the worker processes to exit.
The sample controls determine how the console captures reports from the worker processes. It
is important to understand that these control only the console behavior. They do not adjust the
frequency at which the worker processes send reports. The slider controls the period at which
the console takes a sample. This involves adding up all the reports received over that sample
interval and calculating the TPS as (number of tests that occurred)/(interval length). It is also
the period at which the console graphs and statistics are updated.
Each time the worker processes run, they generate a new set of logs. Logs from previous runs
are “archived” by renaming them. The number of logs that are kept from previous runs can be
controlled with grinder.numberOfOldLogs .
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
You can view a summary of the statistics in tabular format in The Grinder’s console. Click the
Results tab to view the statistics of the test in tabular format.
This graphic is a screenshot of The Grinder console showing statistics.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
You can use the Administration console to quickly monitor the performance of WebLogic
Server instances. The Monitoring tab for each server provides pages that help you monitor the
status and performance of resources associated with the server. Some of the important pages
are:
• The General page provides general runtime information about this server and includes
information such as the current lifecycle state of this server, which JVM is used, and
when the server was started.
• The Health page provides a table showing the health state of the resources in the server.
• The Channels page provides a table showing the name, protocol, and number of active
connections being served by this server.
• The Performance page lets you monitor performance information about this server. You
can also use this page to force garbage collection or a thread dump.
• The Threads page provides information about the thread activity for the current server in
the form of two tables. The first table on this page provides general information about the
status of the thread pool. The second table provides information about individual threads.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
You can also use the Monitoring Dashboard to graphically view the current and historical
operating state of WebLogic Server and hosted applications in a domain. The Monitoring
Dashboard provides a set of tools for organizing and displaying diagnostic data into views,
which surface some of the more critical runtime WebLogic Server performance metrics and the
change in those metrics over time. The Monitoring Dashboard also includes the Metric
Browser. You can use the Metric Browser to select the specific managed bean (MBean) types,
instances, and attributes that you want to monitor in a chart for a selected server. Historical
MBean attribute data is always retrieved from a W LDF archive, which is available if you have
configured the WLDF Harvester to gather metrics data and created that archive. The diagnostic
data displayed by the Monitoring Dashboard consists of runtime MBean attributes with numeric
or Boolean values that are useful to measure, either as their current values or as their changes
over time. These values, referred to in the Monitoring Dashboard as metrics, srcinate from two
sources:
• Directly from active runtime MBean instances: These metrics are sometimes called polled
metrics.
• From the Archive that have been collected by the Harvester: These metrics are also
known as collected metrics.
– Built-in views: A
runtime metrics forset
all of predefined
running viewsServer
W ebLogic of available
instances in
the domain.
– Custom views: Any view created by a user. Custom views
are available only to the user who creates them.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
A view is a collection of one or more charts that display captured monitoring and diagnostic
data. Views are displayed in the main display panel of the Monitoring Dashboard. Only one
view is displayed at a time. Two general types of views can be displayed, created, or modified
in the Monitoring Dashboard:
• Built-in views: A set of predefined views of available runtime metrics for all running
WebLogic Server instances in the domain. Built-in views surface some of the more critical
run-time WebLogic Server performance metrics and serve as examples of the Monitoring
Dashboard's view and graphing capabilities. Built-in views are available for every user
logged into the Administration Console and using the Monitoring Dashboard. You cannot
rename, delete, modify, or save a built-in view.
• Custom views: Any view created by a user. Custom views are available only to the user
who creates them. Custom views are automatically persisted and can be accessed again
in subsequent Monitoring Dashboard sessions. You can also create a custom view by
copying (cloning) a built-in view, and then modifying, renaming, or deleting it as with other
custom views.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
Copyright © 2014, Oracle and/or its affili ates. All rights reserved.
This practice pushes the application to its limits and students compare performance numbers
with baseline numbers and identify bottlenecks of the system.
Metric Meaning
CPU utilization Is probably the most straightforward metric. It
describes the overall utilization per processor.
User time Depicts the CPU percentage spent on user
processes, including nice time. High values in
user time are generally desirable because, in this
case, the system performs actual work
System time Depicts the CPU percentage spent on kernel
operations including IRQ and softirq time. High
and sustained system time values can point you
to bottlenecks in the system, which should
generally spend as little time as possible in kernel
time
CPU utilization: This refers to a computer's usage of processing resources, or the amount of
work handled by a CPU. Actual CPU utilization varies depending on the amount and type of
managed computing tasks. Certain tasks require heavy CPU time, while others require less
because of non-CPU resource requirements.
User Time: This is the amount of time the command spends in "User Mode." User Mode is a
"safety" feature because when a program is in User Mode it cannot cause other programs to
crash, or behave unexpectedly.
System Time: System Time is the amount of time the command spends in "Kernel Mode."
There are certain tasks a command or an application must run in Kernel Mode to accomplish;
however, time spent in "Kernel Mode" is indicative of time spent by the Linux/UNIX
"infrastructure" (system services, context switches, I/O synchronization, etc.) rather than CPU
cycles spent satisfying the application computational requests.
Context Switch: When a CPU switches from one process (or thread) to another, it is called
as context switch. When a process switch happens, the kernel stores the current state of the
CPU (of a process or thread) in the memory. The kernel also retrieves the previously stored
state (of a process or thread) from the memory and puts it in the CPU. Context switching is
very essential for multitasking of the CPU, however, a higher level of context switching can
cause performance issues.
Metric Meaning
Waiting Total amount of CPU time spent waiting for an I/O
operation to occur. Like the blocked value, a
system should not spend too much time waiting
for I/O operations; otherwise, you should
investigate the performance of the respective I/O
subsystem.
Idle time Depicts the CPU percentage the system was idle
waiting for tasks
The nice command is used to run a program with modified scheduling priority/nicenesses.
Nicenesses range at least from -20 (resulting in the most favorable scheduling) through 19
(the least favorable). The default behavior is to increase the niceness by 10. Niceness should
not be confused with a scheduling priority, which lets applications determine the order in
which threads are scheduled to run. Unlike a priority, a niceness is merely advice to the
scheduler, which the scheduler is free to ignore.
Metric Meaning
Free memory Compared to most other operating systems, the
free memory value in Linux should not be a
cause for concern as the Linux kernel allocates
most unused memory as file system cache; so
subtract the amount of buffers and cache from
the used memory to determine (effectively) free
memory.
Swap Usage Depicts the amount of swap space used
Swap In/Out is a reliable means of identifying a memory bottleneck. Values above 200 to 300
pages per second for a sustained period of time express a likely memory bottleneck.
A Slab is a set of one or more contiguous pages of memory set aside by the slab allocator for
an individual cache. This memory is further divided into equal segments the size of the object
type that the cache is managing.
Metric Meaning
Active versus Provides you with information about the active
inactive use of the system memory. Inactive memory is a
memory likely candidate to be swapped out to disk by the
kswapd daemon.
Buffer and The buffers number represents in-memory blocks
cache that result from the kernel accessing the disk,
such as when the kernel needs to read the
contents of files. The cached figure tells you how
much RAM is being used to cache the content of
recently read files. The buffer figure increases
when the file system layer is bypassed while the
cache grows when the file system is used.
Metric Meaning
Packets Informs you about the quantity of packets
received and received and sent by a given network interface
sent
Bytes received Depicts the number of bytes received and sent by
and sent a given network interface
Packets Is a count of packets that have been dropped by
dropped the kernel, either due to a firewall configuration or
due to a lack of network buffers
Overruns Overruns represent the number of times that the
network interface ran out of buffer space
Packet drops in Linux can happen at two layers, either at the NIC level or at the Network
stack level. An abnormal amount of packet drops at NIC level could indicate RX or TX buffers
set to sub-optimal levels.
The overruns metric should be used in conjunction with the packets dropped value to identify
a possible bottleneck in network buffers or the network queue length.
Metric Meaning
Collisions per Provides an indication of the number of collisions
second that occur on the network that the respective
interface is connected to. Sustained values of
collisions often concern a bottleneck in the
network infrastructure, not the server. On most
properly configured networks, collisions are rare
events.
Errors The number of frames marked as faulty. This is
often caused by a network mismatch or a partially
broken network cable. Partially broken network
cables can be a significant performance issue for
copper-based gigabit networks.
Data packets can collide with one another when being sent on a shared medium or through
repeaters. A network collision occurs when more than one device attempts to send a packet
on a network segment at the same time.Collisions are resolved using carrier sense multiple
access with collision detection (CSMA-CD) in which the competing packets are discarded and
re-sent one at a time. This becomes a source of inefficiency in the network.
Only one device in the collision domain may transmit at any one time, and the other devices
in the domain listen to the network in order to avoid data collisions. Because only one device
may be transmitting at any one time, total network bandwidth is shared among all devices.
CRC Errors: Frames were sent but were corrupted in transit. The presence of CRC errors,
but not many collisions usually is an indication of electrical noise. Make sure that you are
using the correct type of cable, that the cabling is undamaged and that the connectors are
securely fastened.
Frame Errors: An incorrect CRC and a non-integer number of bytes are received. This is
usually the result of collisions or a bad Ethernet device.
FIFO and Overrun Errors: The number of times that the NIC was unable of handing data to
its memory buffers because the data rate the capabilities of the hardware. This is usually a
sign of excessive traffic.
Metric Meaning
Iowait Time the CPU spends waiting for an I/O
operation to occur. High and sustained values
most likely indicate an I/O bottleneck.
Average queue Amount of outstanding I/O requests. In general, a
length disk queue of 2 to 3 is optimal; higher values
might point toward a disk I/O bottleneck.
Average wait A measurement of the average time in ms it takes
for an I/O request to be serviced. The wait time
consists of the actual I/O operation and the time it
waited in the I/O queue.
iowait: This number shows the % of time the CPU is wasting in waiting for I/O. A part of this
number can result from network I/O, which can be avoided by using an Async IO library. The
remaining part of it is simply an indication of how I/O-bound your system is.
Average Wait: The percentage of time that I/O operations spent waiting in queue in
comparison to actually being serviced. If this figure goes above 50% then each I/O request is
spending more time waiting in queue than being processed. If this ratio skews heavily
upwards (in the >75% range) you know that your disk subsystem is not being able to keep up
with the I/O requests and most I/O requests are spending a lot of time waiting in queue.
Metric Meaning
Transfers per Depicts how many I/O operations per second are
second performed (reads and writes). The transfers per
second metric in conjunction with the kBytes per
second value helps you to identify the average
transfer size of the system.
Blocks Depicts the reads and writes per second
read/write per expressed in blocks of 1024 bytes as of kernel
second 2.6
Kilobytes per Reads from and writes to the block device in
second kilobytes represent the amount of actual data
read/write transferred to and from the block device.
CPU usage is a very important performance indicator. CPU usage should be measured over
long periods. If the peak CPU usage is sustained at very low values, and the applications are
performing at expected speeds, this indicates that the processor can accommodate more
work. Such a system can be used for scaling up.
You can look at these parameters when monitoring CPU:
• High CPU time: A high (consistently above 60 percent) CPU time indicates a lot of CPU
cycles are affecting performance. A reduction in kernel CPU time will give more CPU
time to the application. Similarly, high sys CPU time could indicate shared resource
contention.
• Idle CPU: The idle CPU can be an indicator of an application's inability to scale.
Combination of high sys or kernel CPU utilization and idle CPU could indicate shared
resource contention as the scalability blocker.
If the CPU usage remains high (near 100 percent) over long periods, and occasional
performance problems arise, then this could mean:
• The system is very heavily used. Such a system cannot handle any further load.
• Some of the applications are not designed efficiently. By tuning these applications, the
CPU usage can be brought to efficient levels.
One single program can very rarely keep the CPU 100 percent busy (that is, 0 percent idle
and 0 percent wait for more than a few seconds at a time). Even in heavily loaded multiuser
systems, there are occasional 10-milliseconds (ms) periods that end with all threads in a wait
state. If a monitor shows the CPU as 100 percent busy for an extended period, there is a good
chance that some program is in an infinite loop.
– CPU usage
– Disk activity
The operating system contains several counters that are incremented as various system
actions occur. These include counters for CPU utilization, buffer usage, disk and tape I/O
activity, standard output (terminal) device activity, switching and system-call activity, file
access, queue activity, interprocess communications, and paging.
The sar command, when executed, reads from these counters and displays information to
the user.
Use the sar command to get real-time sampling and display of current statistics.
To collect and display system statistic reports immediately, use the following command:
# sar -u 2 5
• The values to in
– Processes look
the from the vmstat
run queue ( procs output
r)
are:
– CPU time in user, system, and idle ( cpu us, sy, and id)
Average
since
system
start
The vmstat command quickly provides compact information about various system resources
and their related performance problems. This command reports statistics about kernel threads
in the run and wait queue, memory, paging, disks, interrupts, system calls, context switches,
and CPU activity.
If it is used without any options or only with the interval and optionally, the count parameter,
such as vmstat 2 10, then the first line of numbers reflect the average values since system
started.
You can get detailed help on vmstat from man pages.
Use the iostat command for monitoring system input/output device loading by observing
the time the devices are active in relation to their average transfer rates. The iostat
command generates two types of reports: the CPU Utilization report and the Device Utilization
report.
The typical syntax for the iostat command is:
$> iostat <options> <interval> <count>
• Option: The device for which information is needed such as a d (disk), c (CPU), or t
(terminal)
• Interval: The time period in seconds between two samples
• Count: The number of times the data is needed
Socket information
Proto The protocol (tcp, udp, raw) used by the socket
Recv-Q The count of bytes not copied by the user program connected to this
socket
Send-Q The count of bytes not acknowledged by the remote host
Local Address Address and port number of the local end of the socket. Unless the
--numeric (-n) option is specified, the socket address is resolved to its
canonical host name (FQDN), and the port number is translated into the
corresponding service name.
Foreign Address Address and port number of the remote end of the socket
State The state of the socket. Since there are no states in raw mode and
The System Monitor application enables you to monitor system processes and the usage of
system resources. You can also use the System Monitor to modify the behavior of your
system. The System Monitor window contains three tabbed sections:
• Processes: Shows active processes and how processes are related to each other. It
provides detailed information about individual processes and enables you to control
active processes.
• Resources: Displays the (recent) history of CPU, memory and swap space, and
network usage.
• File Systems: Shows the disk space usage and availability.
You can start the System Monitor in the following ways:
• On the Applications menu, select System Tools > System Monitor.
• On the command line, execute the command:gnome-system-monitor.
Tool Main
Purpose
top Process activity
The mpstat utility enables you to display overall CPU statistics per system or per processor.
mpstat also enables the creation of statistics when used in sampling mode analogous to the
vmstat command with a sampling frequency and a sampling count.
Tool Main
Purpose
pmap Process memory usage
The pmap command reports the amount of memory that one or more processes are using.
You can use this tool to determine which processes on the server are being allocated memory
and whether this amount of memory is a cause of memory bottlenecks. For detailed
information, use pmap -d option.
tcpdump is a simple but robust utility. It has basic protocol analyzing capability allowing you
to get a rough picture of what is happening on the network. tcpdump supports many options
and flexible expressions for filtering the frames to be captured (capture filter).
nmon, short for Nigel's Monitor, is a popular tool to monitor Linux systems performance
developed by Nigel Griffiths. Since nmon incorporates the performance information for
several subsystems, it can be used as a single source for performance monitoring. Some of
the tasks that can be achieved with nmon include processor utilization, memory utilization, run
queue information, disks I/O statistics, network I/O statistics, paging activity, and process
metrics. In order to run nmon, simply start the tool and select the subsystems of interest by
typing their one-key commands. For example, to get CPU, memory, and disk statistics, start
nmon and type c m d.
The Linux command sar (short for System Activity Report) prints to the standard output
device the selected activity details. You can use the sar –b command effectively to monitor
the I/O operations.
• For example, the following is a portion of output from sar –b command:
11:40:01 AM tps rtps wtps bread/s bwrtn/s
11:50:01 AM 0.73 0.00 0.73 0.00 9.61
12:00:01 PM 0.72 0.00 0.72 0.00 9.53
12:10:01 PM 0.87 0.00 0.87 0.00 12.87
12:20:01 PM 0.72 0.00 0.72 0.00 9.17
12:30:01 PM 0.83 0.01 0.82 2.34 11.98
12:40:01 PM 1.55 0.19 1.36 7.48 31.82
Average: 1.46 0.60 0.87 7.98 16.13
• However, frequent
performance paging
problems and swapping can cause
because:
– The CPU cycles are spent in moving data from and to disks
– Disk thrashing may occur with frequent swapping
– Page faults can occur when contiguous area is not available
• You can use vmstat to monitor swapping.
Paging and swapping are methods for moving data ni memory to a storage device such as a
hard drive.
Swapping moves complete memory structures for a process to a specified area on the hard
disk. The specified area is referred to as swap area. The process goes from the state of being
in memory to being swapped out entirely. The advantage of swapping is that memory for a
program is allocated contiguously. However, performance can be adversely affected when the
system ends up constantly swapping in and out of disk—a situation often referred to as
thrashing.
Paging involves portioning process memory into pages and writing out pages of process
memory rather than entire process memory. This reduces time and amount of disk i/o
involved. But this would mean that more of the memory still remains occupied even though
the corresponding process cannot be effectively operated upon.
You can reduce swapping by:
•
• The percentage
having of inode
active pages s that can
in memory werebeoverwritten while
retrieved by still
using
the following command:
sar -v
• If this number is consistently nonzero, theinode cache
should be increased.
The VFS maintains an inode cache to speed up accesses to all the mounted file systems.
The inode cache is implemented as a linked list that stores the inodes that have been
accessed along with pointers to all pages that are part of that file and are currently in memory.
Every time a VFS inode is read from the inode cache, the system saves an access to a
physical device. The entries in the inode cache stay in the cache until the system removes
them to make room for newer entries.
To determine whether theinode cache is large enough, check the following sar columns:
iget/s, namei/s, and dirbk/s. The first column (iget/s) tells how frequently inode had
to be accessed from the disk. The latter two columns indicate the demand on the file system
(for file name-to-inode translation and directory-block scanning). If iget/s values are
frequently too high (greater than five, or so), you may need a larger inode cache. If namei/s
is more than ten times greater than iget/s, you may benefit from a largerinode cache.
Reconfigure and check again.
fs.file-max=65535
• Run sysctl –p to load the new value or reboot the
system for the change to take effect.
The /proc/sys/fs/file-maxparameter sets the maximum number of file handles that the
Linux kernel will allocate. This parameter is tuned to improve the number of open files by
increasing the value of /proc/sys/fs/file-maxto 65535.
When the number approaches the maximum number of file descriptors per process, new
connections have to wait for a free space in the application’s file descriptor table.
One of the problems found in servers with a lot of simultaneous TCP connections is the large
number of connections that are open but unused.
TCP has a keepalive function that probes these connections. By default, the keepalive
routines wait for two hours (7200 secs) before sending the first keepalive probe; after that,
then resend it every 75 seconds. If no ACK response is received for nine consecutive times,
the connection is marked as broken. This length of time might be too long for the server and
could result in excess memory usage and a decrease in server performance. Setting it to
1800 seconds (30 minutes), for example, might be more appropriate:
net.ipv4.tcp_keepalive_time=1800.
With these parameters enabled, the number of connections is significantly reduced. This is
good for performance because each TCP transaction maintains a cache of protocol
information about each of the remote clients. In this cache, information such as round-trip
time, maximum segment size, and congestion window are stored.
Aspect Description
Memory Footprint The amount of memory used by an application and the JVM
There are several ways in which you can define performance. Some of these aspects of
performance impact the JVM.
Each of these aspects should be a well-defined requirement for an application. In addition, the
importance should be prioritized for the application. This clarification is an important input to
the folks who are tackling the application's performance issues.
Memory Footprint: It is very important to know the environment and ecosystem in which your
application runs. Shared resources can have a significant impact on performance.
Virtual memory swapping should be minimized for any Java application. Consider a scenario
where a garbage collection occurs with a large portion of the Java heap in virtual memory.
Scanning for referenced objects would take much longer than when the heap is in physical
memory. It is very important to configure a system and the Java heap to avoid virtual memory
swapping. Questions to ask yourself include:
• Does the application run on a dedicated system?
• Does the application share the machine with other applications and JVMs?
line is that
typically a responsive
more application
focused on returns Long
responsiveness. requested
pausedata
timequickly.
are notClient applications are
acceptable.
Throughput: Server applications typically focus more on throughput and less on
responsiveness. High pause times are more acceptable, but still avoided if at all possible.
jmap and jhat Tools that dump and display heap and
shared object memory map
jstack Tool that prints Java stack traces of Java
threads
You can use the tools listed in the slide to monitor JVM performance and resource
consumption. You can also use some of the tools for troubleshooting. Java VisualVM,
jconsole, Mission Control, and Flight Recorder are GUI-based tools that require X-Windows
in Linux and UNIX environments. All of the other tools are command line–based tools.
Al i veo b j e c t U nr e f e r e nc e dO b j e c t s M e mo rys p ac e
Before marking
After marking
After normal
deletion with
compacting
Garbage collection is a way in which Java recollects the space occupied by loitering objects.
In general, a garbage collector is responsible for three tasks:
• Allocating memory for new objects
• Ensuring that any referenced objects (live objects) remain in memory
• Recovering memory used by objects that are no longer reachable (dead objects)
Marking: The first step that the garbage collector performs is called marking. The garbage
collector iterates each object one by one through the application graph, checks whether the
object is being referenced, and if so marks the object as being used. The marked objects will
not be deleted in the sweeping stage.
Normal Deletion: The deletion of objects happens in the sweeping stage. The traditional and
easiest way is to mark the space as free and let the allocator use complex data structures to
search the memory for the required free space.
Compacting: It is obvious that the traditional way of freeing memory has many problems
associated with it. An improved way is by providing a defragmenting system that compacts
memory by moving objects closer to each other and removes fragments of free space, if any.
In this way, the allocation of future objects is much faster.
GC occurs quickly and frequently here. GC occurs less frequently and can take longer.
Non-generational garbage collectors iterate over every object in the heap and check whether
or not the object has some active references to it. As the number of objects increases in the
heap, this process would take a longer time to complete, and therefore, would be inefficient.
A careful observation of a typical object would tell us the following two characteristics:
• Most allocated objects will die young.
• Few references from older to younger objects exist.
To take advantage of this, the Java HotSpot VM splits the heap into different physical areas,
which are called generations. HotSpot uses a type of garbage collection that is termed
generational. This means that the Java heap is partitioned into generational spaces. The
default arrangement of generations (for all collectors with the exception of the throughput
collector) looks something like the image in the slide.
There are three types of generational spaces:
• Young Generation
• Tenured Generation
• Permanent Generation
-Xmx -XX:MaxPermSize
-Xms -XX:PermSize
-XX:NewSize
r r r
e e e
s s s
e e e
r r r
v
e
To From Eden Tenured v
e
Perm v
e
d d d
-XX:MaxNewSize
(virtually committed).
$ export USER_MEM_ARGS="–Xms1g –Xmx2g"
$ startManagedWebLogic.sh myserver ...
Command Line
Property Description
-Xms<size> Initial heap size
Configuring the Java HotSpot heap size options when starting WebLogic Server increases
performance for most applications. These options may differ depending on your architecture
and operating system.
• -Xms
- This parameter configures the starting and minimum size of the Java heap.
- As a general rule, set this value to be equivalent to the maximum heap size
parameter (Xmx) to avoid expensive growing and shrinking of the heap.
• -Xmx
- This parameter configures the maximum size of the Java heap.
- Set this value to accommodate all the objects of your application. When the
objects in memory require more space than specified by the–Xmx value, you get
“Out of memory” errors.
- If a value is too large, it can deprive memory for other services running on the
computer and can cause paging and thrashing.
O S S O O
E Eden Space
O O E O
S Survivor Space
O Old Generation
The heap is one memory area split into many fixed sized regions. Region size is chosen by
the JVM at startup. The JVM generally targets around 2000 regions varying in size from 1 to
32 MB. Regions are not required to be contiguous like the older garbage collectors.
A remember set is kept for each region, which is a list with references to objects. Threads
inform the garbage collector when they change a reference, which can change the remember
set. When a garbage collection occurs, the areas containing the most free space (or garbage)
are collected first, hence the nickname, garbage-first. The idea behind this method is that the
most common scenario for garbage collection will be that several regions will exist that
contain no living objects. The garbage collector can then simply free the regions without
requiring the mark-and-sweep or compacting processes, which speeds up GC performance.
-XX:+UseParallelGC Parallel
With the advent of Ergonomics, most command-line switches are redundant. However, in
some specific cases, you may need to use these switches. The table shows HotSpot VM
options with the option description and the associated generation.
• Serial: The serial collector is a single-threaded, stop the world, garbage collector. It is
best used on single CPU systems where multithreading collection would not provide
increased performance.
• Parallel: Considering that hardware resources (CPU and memory) are getting to be
relatively inexpensive, the parallel collector, also known as the throughput collector,
enables you to take advantage of available CPUs rather than leaving most of them idle
while only one does garbage-collection work.
• Parallel compacting: The difference between the parallel compaction collector and the
parallel collector is that the parallel compaction collector uses a young algorithm for
garbage collection of the old generation. With the parallel compaction collector, the old
and permanent generations are collected in a mostly parallel fashion with sliding
compaction. By default, only minor collections are executed in parallel and major
collections are performed with a single thread. This option enables parallel compaction
for major and minor collections.
Throughput is the percentage of total time not spent in garbage collection, considered over
long periods of time. Throughput includes time spent in allocation (but tuning for speed of
allocation is generally not needed). Pauses are the times when an application appears
unresponsive because garbage collection is occurring. A responsive application attempts to
reduce the length of these pauses.
Users have different requirements of garbage collection. For example, some consider the
right metric for a web server to be throughput, because pauses during garbage collection may
be tolerable, or simply obscured by network latencies. However, in an interactive graphics
program even short pauses may negatively affect the user experience.
Some users are sensitive to other considerations. Footprint is the working set of a process,
measured in pages and cache lines. On systems with limited physical memory or many
processes, footprint may dictate scalability.
There are numerous ways to size generations. The best choice is determined by the way the
application uses memory as well as user requirements.
Throughput:
• Has as highest priority the raw throughput of the
information or data being processed
• Maximizes application throughput even at the expense of
responsiveness
• Will tolerate high pause times in order to maximize
throughput
A Java application that focuses on throughput emphasizes the raw throughput of the
information or data being processed. This is the most important quality for the application.
Pause times resulting from JVM garbage collection events are not an issue, or of very little
interest. As long as the overall throughput of the application over a period of time is not
sacrificed, long pause times are allowed. Examples of applications that focus on throughput
include:
• A large phone company printing bills or statements
• A large credit card company printing statements
• A bank calculating interest for accounts
Responsiveness
• Have as highest priority the servicing of requests within a
predefined maximum time
• Raw throughput of data or speed of processing requests
C ri t e ri a Description
Pause time Does the collector introduce pauses by stopping the world?
Memory footprint What is the total memory allocated versus the total memory available
to the application?
Virtual memory usage and How efficiently does the garbage collector manage the reference for
interaction pages outside the resident memory during a full GC?
Concurrency Is there a contention for a CPU between application threads and the
garbage collector?
Can this be overcome by use of systems with multiple CPUs?
Compiler Are compile-time operations causing issues?
Increasing the size for permanent generation can be helpful if there are numerous
dynamically generated classes. However, you should bear in mind that you should increase
-XX:MaxPermSize along with -XX:PermSize. To tune this, you may set-XX:PermSize
as high as -XX:MaxPermSize and then reduce it to an appropriate level when you know
your typical requirements.
For more information about tuning HotSpot JVM, refer to GCPortal at:
http://www.oracle.com/technetwork/articles/javase/gcportal-
136937.html
GCPortal enables a service, Application Modeling, and Performance Tuning from a GC
perspective. It is implemented in J2EE and available as a J2EE W AR module that can run on
any J2EE Application Server. It allows developers to submit log files and analyze application
behavior.
You can use GCPortal to performance tune and size the application to run optimally under
lean, peak, and burst conditions.
To find more information about aggressive options, use -XX:+PrintCommandLine.
Yes No
CPUs > 1 No
&& Mem >=
2GB? Setting
Yes PRODUCTION_MODE
Server Class to true causes
Machine
WebLogic to start
using -server option.
In J2SE 5.0 or later, when a machine with at least two CPUs and at least 2 GB of physical
memory is used, it is said to be a server-class machine.
During JVM launch, the JVM detects whether the application or server is running in a
server-class machine; if so, the Java HotSpot Server VM is used.
Server-class detection occurs if you do not specify -server or -client when launching
the application on an Intel or SPARC 32-bit machine running Solaris or Linux. Windows
machines always default to the client VM. All 64-bit platforms default to the server VM.
The PRODUCTION_MODE parameter in setDomainEnv.sh can be set to “true” to start server
mode JVM.
The client VM focuses on faster start up time for iterative development and faster response
time for users. This VM starts up quickly, but may not perform as fast as the server VM over
time.
The server VM starts up more slowly than the client VM, but performs faster over time.
The J2SE Platform version 1.5 or later offers a feature called ergonomics. The goal of
ergonomics is good JVM performance with a minimum of command-line tuning. When
ergonomics is enabled, the JVM attempts to match the best settings for an application.
On server-class machines, by default, the following are selected:
• Server JIT compiler
• Throughput garbage collector
• Heap sizes
• Initial heap size of 1/64 of physical memory up to 1 GB
• Maximum heap size of 1/4 of physical memory up to 1 GB
If not identified as a server class, then runs as a client class:
• Client JIT compiler
• Default serial collector, same as before
jps is very similar to ps in UNIX. Its purpose is to identify the process ID of Java processes.
If jps is run without specifying a hostid, it looks for instrumented JVMs on the local host. If
jps is started with a hostid, it looks for JVMs on the indicated host, using the specified
protocol and port. This can be used to retrieve the virtual machine identifier (vmid) or Local
Virtual Machine Identifier (lvmid), which can be used as an input for other commands.
Note: See the jps man page on oracle.com for details about-q, -mlvV options:
http://download.oracle.com/javase/7/docs/technotes/tools/share/jps.html
19539 Server
Command Line
The list of JVMs produced by the jps command may be limited by the permissions granted to
the principal running the command. The command lists only the JVMs for which the principal
has access rights as determined by operating system–specific access control mechanisms.
This command is important to retrieve thelvmids of the JVMs running so that you can use
them in other commands.
The screenshot shows the result of ajps call.
The jcmd (pronounced "j command") utility is a new diagnostic tool that can look up process
IDs of running JVMs and also send diagnostic commands to a running JVM. The following are
some example jcmd commands.
• jcmd: Returns the PID of all running JVMs on the system
• jcmd 1234 VM.flags : Displays the command-line options used to start the JVM with a
PID of 1234
• jcmd java2 VM.flags : Displays the command-line options used to start the JVM
whose name includes the string "Java2"
• jcmd 0 VM.flags : Displays the command-line options used to start all the running JVM
instances on this machine
• JVM information
$ jcmd 1234 VM.uptime
$ jcmd 1234 VM.command_line
$ jcmd 1234 VM.version
$ jcmd 1234 VM.system_properties Command Line
• jcmd 1234 help : Lists all the options available on this JVM
• jcmd 1234 help -all : Lists all the options available on this JVM and prints a brief
description of each option
• jcmd 1234 VM.uptime : Displays the amount of time the JVM has been up
• jcmd 1234 VM.command_line : Shows the command used to start the JVM and the
command-line options
• jcmd 1234 VM.version : Shows the version of the JVM
• jcmd 1234 VM.system_properties : Displays the system properties for the
selected JVM
Command Line
jcmd 1234 GC.class_histogram: Displays a list of classes taking up the most memory.
You may want to redirect the output to a file because it can be very long.
$ jinfo 19719
Attaching to process ID 19719, please wait...
jstat is a command-line tool that displays detailed performance statistics for a local or
remote HotSpot VM. The–gcutil command-line option is used most frequently.
For information about garbage collection options, see the man page at:
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html
Caution: When using the CMS collector (also known as concurrent collector), jstat reports
two full GC events per CMS cycle, which is obviously misleading. However, young generation
stats are accurate with the CMS collector.
Syntax:
jstack [ option ] pid | executable core |[server-id@]remote-
hostname-or-IP
• pid: Java process ID
• executable: Java executable from which the core dump was produced
• core: The core file for which the configuration information is to be printed
• server-id: Unique server ID
• remote-hostname-or-IP: Remote server’s IP or hostname
For each Java frame, the full class name, method name, “bci” (byte code index), and line
number, if available, are printed.
Refer to the following URL for more information:
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstack.html
A stack trace of all threads can be useful when you are trying to diagnose a number of issues
such as deadlocks or hangs. Deadlocks and hangs may consume a server’s resources more,
which may let the user request deprive or starve. Diagnosing and eliminating these issues
from applications deployed on WebLogic Server increases the performance of the server.
The following are the possible thread states:
• NEW: Thread has been created, but it has not started running yet.
• IN_NATIVE: Thread is running native code.
• IN_VM: Thread is running VM code.
• IN_JAVA: Thread is running (either interpreted or compiled) Java code.
• BLOCKED: Thread is blocked.
• ..._TRANS: If you see any of the preceding states followed by “_TRANS,” it means that
the thread is changing to a different state.
• UNINTIALIZED: Thread is not created. This will normally not happen (unless there is a
serious bug such as memory corruption).
The screenshots show an example of runningjstack.
JMX-based
Management
Java application Application
(Example: Java
Instrumentation VisualVM)
Platform
MBean
Server
Instrumentation
SNMP
Java Virtual Machine MIB
SNMP-based
Management
Operating system Application
(Example: HP
Network Node
Manager)
The graphic shows the Java Management Extensions (JMX)-based management applications
and Simple Network Management Protocol (SNMP)-based management applications
connecting to Java applications facilitating remote management.
Java has greatly expanded JVM monitoring and management support capabilities and
included the Java VisualVM, jconsole, Mission Control, and Flight Recorder tools to take
advantage of these capabilities.
When an application is run with JMX enabled, a JMX Agent process is activated within the
JVM to manage JMX requests. JMX clients can then locate and connect to the JMX agent
and query it for the available management resources.
JMX was later complemented with the JMX Remote API (JSR 160), which allowed remote
clients to access the JMX agent. The JMX Remote API includes access control and secure
sockets layer (SSL) support, which makes it secure enough for use in production.
An MBean is a managed object that follows the design patterns conforming to the JMX
specification. An MBean can represent a device, an application, or any resource that must be
managed. The management interface of an MBean comprises a set of readable and writable
attributes, and a set of invocable operations. MBeans can also emit notifications when
predefined events occur.
Java VisualVM, first made available with JDK version 6, update 7, is a graphical user
interface that provides information about Java applications and the JVM on which the
applications run. Java VisualVM federates several monitoring, troubleshooting, and profiling
utilities such as jmap, jinfo, and jstack to obtain data from the JVM software, and then
reorganizes and presents the information graphically.
You can view different data about multiple Java applications uniformly, whether they are
running locally or on remote machines.
Java VisualVM can be used by Java application developers to troubleshoot applications and
to monitor and improve the applications’ performance. Java VisualVM can allow developers to
generate and analyze heap dumps, track down memory leaks, browse the platform’s MBeans
and perform operations on those MBeans, perform and monitor garbage collection, and
perform lightweight memory and CPU profiling.
When started without any arguments, Java VisualVM automatically detects all JVMs running
locally. In a production environment, it is recommended to run Java VisualVM on a separate
machine so as to minimize contention for system resources. The screenshot shows Java
VisualVM connected to two local JVM instances.
Note: A non-RMI connector could be SNMP based.
• For security,
password when remote
authentication monitoring
over is enabled,
SSL is enabled by default.
You can use Java VisualVM to monitor applications and JVMs running on remote hosts. Java
VisualVM can display general data about the application’s run-time environment and can
monitor memory heap and thread activity; however, Java VisualVM cannot profile remote
applications.
You can add a remote host as follows:
1. Right-click the Remote node in the Applications window.
2. Select Add Remote Host.
3. Enter the host name or IP address in the Add Remote Host dialog box. (You can also
specify a display name that will be used to refer to the host when listed under the
Remote node.)
Connected remote hosts are displayed as nodes and the applications running on the host as
subnodes under the Remote branch of the Applications window.
The Applications
window contains a
tree of JVMs that are
visible to Java
VisualVM.
The screenshot shows the Java VisualVM interface after connecting to a HotSpot JVM. There
are two main panels in this interface: the Applications window and the Monitoring Panel.
The Applications window:
• The Applications window is the main point of entry for exploring the details of running
JVMs. This window uses a tree structure to enable you to quickly view the JVMs
(running on the local and any connected remote systems) that are visible to this Java
VisualVM. In Solaris and Linux systems, you can also access core dumps and saved
snapshots from the Applications window.
• You can right-click a node in the Applications window and use the pop-up menu to
perform actions related to that node, including opening application tabs, taking heap and
thread dumps, and opening snapshots in the main window.
The Monitoring Panel contains statistics and graphs on the applications to which you have
connected.
The Threads tab presents high-level data on thread activity. The Threads tab is visible if Java
VisualVM can make a JMX connection and retrieve JMX instrumentation from the JVM.
If the target is local and based on Java 6 or later, then the JMX connection is made
automatically. If the application is running on an older version, you may need to explicitly
establish a JMX connection with the JVM software.
By default, the Threads tab displays a timeline of the current thread activity. You can click a
thread in the timeline to view details about that thread on the Details tab.
Using the Thread Dump button, you can force a stack trace while a local application is
running. A thread dump includes thread states for the active Java threads. It does not stop the
application. You can use a stack trace to help diagnose a number of issues such as
deadlocks or when an application hangs. Using Java VisualVM to take a thread dump can be
very convenient where you do not have a command-line console for the application.
Profiler snapshots capture profiling data at the moment the snapshot is taken. You can take a
profiler snapshot at any time during a profiling session. After you take the snapshot, stop the
profiling session to reduce resource contentions.
When you take a profiler snapshot, a node representing the snapshot appears below the
application node in the Applications window and a temporary snapshot file is written to your
local system in the Java VisualVM user directory.
You can take the following types of profiler snapshots by using Java VisualVM:
• Memory snapshot: A memory snapshot captures profiling data on allocated objects.
You can take a memory snapshot when you are using the profiler to analyze memory
usage.
• CPU snapshot: A CPU snapshot captures data on the performance of the application.
You can take a CPU snapshot when you are using the profiler to analyze application
performance.
Visually observe
Includes class loading and JIT
garbage collection!
compilation information
VisualGC is a stand-alone graphical JVM monitor or a VisualVM plug-in. In this course and
typically, VisualGC is used as a VisualVM plug-in. You can install it directly by using the
VisualVM plug-in center. With VisualGC, a picture is worth a thousand words, because you can
see visually exactly what is going on with the garbage collector. In addition to garbage
collection, VisualGC also provides information about class loading and JIT compilation.
jconsole is a graphical monitoring and management console that comes with the HotSpot
JDK. jconsole supports both Java Management Extensions (JMX) and MBean technology.
This allows jconsole to monitor multiple JVMs at the same time. In addition, more than one
jconsole session can monitor a single JVM session at the same time.jconsole can
monitor the following JVM features:
• Memory usage by memory pool/spaces
• Class loading
• JIT compilation
• Garbage collection
• Threading and logging
• Thread monitor contention
Note: MBeans are managed beans, which are Java objects that represent resources to be
managed. They can be used with JMX applications. Multiple jconsole sessions can attach
to a single JVM.
Summarizes GC activity
obtained from GC logs
GCHisto is a stand-alone GUI for analyzing GC log data. (There is also a VisualVM plug-in
under development.) You can analyze multiple log files at the same time. GCHisto also
allows the comparison of heap sizes or collector types for JVM tuning by comparing GC logs.
Open Source Project: http://gchisto.dev.java.net
Flight Recorder Records and analyzes the JVM and running applications
Mission Control is a set of tools for managing, monitoring, profiling, and troubleshooting your
Java applications. Mission Control uses data collected from the Hotspot JVM as a part of its
normal operations, thus minimizing the performance overhead. The main tools available in
Mission Control are:
• Management Console: The Management Console views real-time behavior of your
application and JVM. Features include the ability to create rules that trigger on certain
events (for example, an email will be sent if the CPU reaches a 90% load).
• Flight Recorder: Records performance data over a period of time. Typical information
recorded includes the Java heap distribution, garbage collections, method samples,
latency data, and lock profiling information.
• JMX Agent: Provides access to all MBeans deployed in the platform MBean server.
Using these MBeans, you can read attribute information, such as garbage collection
pause times.
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.autodiscovery=true
Mission
Control
Machine Machine
You configure JMX remote connectivity with your JVMs using Java options that enable JDP.
Mission Control is configured to automatically discover JDP-enabled JVMs. This connection
uses SSL and a username and password login by default. The options in the slide bypass this
security for development environments.
Recordings
JMX agent
JVM Process
The main focus of Mission Control is to do the necessary instrumentation with the lowest
possible impact on the running system. The technology used also enables the application to
run at full speed after the tool is disconnected from the JVM, which makes Mission Control
uniquely suitable for use in production environments.
The graphic shows that the management console interfaces with the JMX agent. The Flight
Recorder is able to analyze and display results of generated recordings.
Remote
JVMs
Process ID
When you launch Mission Control, the JVM Browser is opened. The JVM Browser is a tree
view that you can use to manage your JVM connections. It automatically discovers locally
running JVMs as well as JVMs on the network that have been started using JDP. Other plug-
ins, such as the Flight Recorder tool, use the JVM Browser to access the connections to
JVMs to record.
Although Mission Control should discover your JVMs automatically, you can also explicitly
create a connection to a JVM. Within the JVM Browser pane, click the Create a new custom
JVM connection button. Enter a Host , Port, and Connection Name. Mission Control can
only connect to JVMs that have enabled remote JMX connectivity.
To start other Mission Control tools such as the Management Console, select a running JVM,
right-click the JVM, and select an application.
To update user preferences for the JVM Browser or other plug-ins, select Window >
Preferences from the main menu.
Management Console
The Mission Control Management Console is displayed above. To open it, select a running
JVM from the JVM Browser on the left side of the interface. Once selected, right-click and
select Start JMX Console.
The General page is shown with the Overview tab by default. The page shows information
about CPU Usage along with Garbage Collection memory. Any part of the Overview tab can
be customized.
The Server Information tab shows key information about this JVM and the current operating
system.
The MBean Browser tab provides access to detailed information about the selected JVM. The
default attributes tab is shown in this screenshot. The selected Operating System attribute
provides information about the current JVM and the operating system on which it is running.
The Operations tab provides access to special attributes that may be queried for information
or changed via the interface. So it provides a way to make changes to a running JVM.
The Notifications tab allows you to subscribe to attributes that periodically publish data. In the
example shown, data about minor garbage collections is recorded to the interface.
The Triggers tab allows you to set triggers based on JVM events. Set the conditions for the
trigger as shown in this screenshot. Then, the Action tab allows you to specify how you get
notified, anything from a dialog popup to an email.
This is the System tab from the Runtime page. It contains general information about the JVM.
The Memory tab shows detailed information about the heap and memory.
The Garbage Collection tab shows information about the number of collections and time-
related information.
Like VisualGC,
but simpler
The Memory Pools tab shows real-time information about the various memory components of
the JVM.
The Thread tab shows information about threads in the JVM. You can enable a number of
attractive features using the check boxes at the top of the table. Detailed information per
thread about:
• CPU Usage
• Deadlocks
• Memory Allocation
The Java Flight Recorder is a performance monitoring and profiling tool that makes
diagnostics information always available, even in the wake of catastrophic failure, such as a
system crash.
JFR is a rotating buffer of diagnostics and profiling data that is always available on demand.
You might consider it a sort of time machine that enables you to go back in time to gather
diagnostics data leading up to an event. The data stored in the rotating buffer includes JVM
and application events. Because JFR is always on, using the default configuration will not
result in any performance overhead.
• JFR runtime is the actual recording agent and comprises these components:
- The Flight Recorder agent, which controls buffers, disk I/O, MBeans, and so on.
This component provides a dynamic library that mixes C and Java code and also
provides a JVM-independent pure Java implementation.
- Producers, which insert data in the Flight Recorder buffer. Producers include the
Flight Recorder offers a low-to-zero overhead process that has the following benefits:
• Always on: You no longer need to restart a broken application and create a recording.
Because the Flight Recorder runs at the time the problem occurs, it provides you with
information from before the time you were alerted of the problem. Runtime analysis data
is always available in the buffer; providing a record of the problem you can diagnose it
based upon the actual event. This feature helps diagnose intermittent problems because
you do not have to start a recording and hope the problem happens again.
• Allows for third-party event providers: A set of APIs allow the Flight Recorder to
monitor third-party applications, including WebLogic and other Oracle products. This
means that you will receive JVM-level detail combined with logic from the Java
application running on the JVM.
• Reduces total cost of ownership: Because you spend less time diagnosing and
troubleshooting problems, the Flight Recorder helps reduce operating costs, reduce
business interrupts, provide faster resolution time when problems occur, and improve
system efficiency.
Java
events
JVM
events
Data is sent to the recorder by the JVM (through internal APIs), and by the Java application
(through the Flight Recorder APIs). The Flight Recorder runtime stores this data in small
thread-local buffers that are flushed to a global in-memory buffer. The data in the in-memory
buffer will be moved from the in-memory buffer to a disk buffer when running in persistent
storage mode.
Buffers are critical to the efficacy of the Flight Recorder. The size of the buffer determines
when and how data is removed from the disk buffers. Data can be discarded after evaluating
either its age or the size of the buffer.
You can configure the buffer sizing mode at the command line when you start the Flight
Recorder. You can select from one of two modes:
• Time-bound mode: In the Time-bound sizing mode, the Flight Recorder keeps data for
a certain period of time. Data that has expired will be removed from the disk.
• Space-bound sizing mode: The Flight Recorder will always keep the size of the
buffers
time. bounded, so the maximum age of the events in the buffer may vary from time to
The screenshot shows an example of initiating performance data recording by using the
Management Console. After a recording is completed, Mission Control opens the recording in
a new tab and shows the view of performance data. You can save this data for further
analysis and comparison with other recordings.
Description
General information about the recording and the recorded application and JVM
Generic information about selected events based upon event types selected in the
Events Type View
Heap,
CPU,
and GC
Pause
statistics
Tabs
CPU and heap data
Tabs
The General tab of the Flight Recorder displays high-level information about the recording. It
displays memory usage, CPU usage, and system properties of the JVM. The VM arguments
that you specified on the command line when starting the JVM are also available on the
General tab. You can achieve a very high level of understanding by investigating this data.
For more information about the specific areas, further investigation is required on the subtabs
on the bottom of the page, or the other tab groups.
Machine
memory
and
Java
GC data heap
statistics
Tabs
The Overview tab provides the broad picture of the memory usage during the Flight Recorder
session. The tab has two graphs:
• The Events and Operatives Set: Shows the graph of when a particular event occurred.
By default a set of events, such as garbage collection, are predefined. In addition, you
can also define events based on your application logic.
• Memory Usage: Shows a graphic representation of the memory used during a Flight
Recorder session.
The two tables on the bottom, namely GC Configuration and GC Statistics, provide average
and maximum statistics relating to the memory (heap) usage and garbage collection during
the session.
Tabs
Heap,
and GC
Pause
statistics
Tabs
More
detailed
GC data
Tabs
The GC Collections tab gives information about the garbage collected during the recording.
The charts show heap usage.
In the Garbage Collections table, you see a list of garbage collection with the time taken and
the generation of heap affected by garbage collection. When you select a GC in the list, you
can find more details under the appropriate subtab in the Details table.
Classes
using
the heap
Top
growing
objects
Tabs
The Object Statistics tab shows the number of instances and cumulative memory used by
different classes during the Flight Recorder session. The Top Growers table provides details
of the classes that are growing. Unbridled growth of objects can indicate a memory leak.
In this section, you should have learned how to use GUI JVM
monitoring tools.
connect()
edit()
startEdit()
cmo.setInternalAppsDeployOnDemandEnabled(true)
activate()
WebLogic deploys many internal applications during startup. Many of these internal
applications are not needed by every user. You can configure WebLogic to wait and deploy
internal applications on first access (on demand) instead of always deploying them during
server startup. This can conserve memory and CPU time during deployment as well as
improve startup time and decrease the base memory footprint for the server.
In a development domain, the default is for WebLogic to deploy internal applications on
demand. For a production-mode domain, the default is for WebLogic to deploy internal
applications as part of server startup.
In production mode, you can change the InternalAppsDeployOnDemandEnabled
attribute using the Administration Console:
1. Click Lock & Edit to start an edit session.
2. Select the domain to bring up the Configuration > General tab.
3. Change the setting of the “Enable on -demand deployment of internal applications”
check box.
4. Click Save, and then click Activate Changes to activate the changes that will take effect
at the next restart of W ebLogic.
Ensure that you do not have too many or uneven TCP connection
counts across managed servers.
WebLogic diagnoses a thread as stuck if it is continually working (not idle) for a set period of
time. You can tune a server’s thread detection behavior by changing the length of time before
a thread is diagnosed as stuck, and by changing the frequency with which the server checks
for stuck threads.
You can configure stuck thread detection behavior for each WebLogic server by using the
Server Configuration > Tuning tab of the Administration Console:
• In the Configuration > Tuning tab, update these parameters as necessary:
- Stuck Thread Max Time: Amount of time, in seconds, that a thread must be
continually working before a server instance diagnoses a thread as being stuck. By
default, WebLogic considers a thread to be “stuck” after 600 seconds of
continuous use.
- Stuck Thread Timer Interval: Amount of time, in seconds, after which a server
instance periodically scans threads to see whether they have been continually
working for600
interval to theseconds.
configured Stuck Thread Max Time. By default, WebLogic sets this
Note: You configure stuck thread detection parameters on a per-server basis.
Max Stuck Thread Time: The number of seconds that a thread must be continually working
before this server diagnoses the thread as being stuck. For example, if you set this to 600
seconds, WebLogic considers a thread to be stuck after 600 seconds of continuous use.
Stuck Thread Count: The number of stuck threads after which the server is transitioned into
a FAILED state. There are options in OverloadProtectionMBean to suspend and shut down a
FAILED server. By default, the server continues to run in a FAILED state. If the Stuck Thread
Count value is set to 0, the server never transitions into the FAILED server irrespective of the
number of stuck threads.
Stuck Thread Timer Interval: The number of seconds after which W ebLogic periodically
scans threads to see whether they have been continually working for the configured maximum
length of time.
The screenshot shows how to set the Max Time and Timer Interval.
Thresholds include:
• Max Stuck
Thread Time
• Stuck Thread
Count
• Failure Action
The screenshot shows how to set the Failure Action, the Max Stuck Thread Time, and Stuck
Thread Count.
IMPORTANT: To force W ebLogic Server to reboot the server which incurred the stuck thread
threshold (or to suspend it), it is crucial to set the "Stuck Thread Count" parameter to a
number different from zero; otherwise, the "Failure Action" will be disregarded.
The screenshot shows how to set the option to perform an auto restart.
Connection backlog buffering is the number of connection requests that a WebLogic Server
instance will accept before refusing additional requests. The accept-backlog parameter in
config.xml specifies how many Transmission Control Protocol (TCP) connections can be
buffered in a wait queue.
The fixed-size queue is populated with requests for connections that the TCP stack has
received, but the application has not yet accepted.
The screenshot shows where to configure the Accept Backlog setting in the Administration
Console.
To address connection backlog, you may also have to tune TCP parameters at the operating
system. In a Linux environment, the following parameters may be of significance:
/sbin/ifconfig lo mtu
kernel.msgmni
kernel.sem
kernel.shmmax
fs.file-max
net.ipv4.tcp_max_syn_backlog
• You should
balance try different
between Accept
refusing Backlog frequently
connections values andand
find a
running the server with extraordinary load.
Raise the Accept Backlog value from the default by 25 percent for every “connection refused”
message when accessing WebLogic.
Setting the backlog to 0 prevents accepting incoming connections on some OS.
A guideline for setting Connection Backlog Buffering is 8,192 for a server with 4 GB of
physical memory.
• To enhance
individual SSL
SSL performance,
connections anddecrease the number of
handshakes.
• Use hardware accelerators to offload SSL processing from
the application server to the dedicated SSL accelerator.
SSL is also known as Secure HTTP (HTTPS) because it defines secure wrapping,
authentication, and encryption for HTTP content. From a performance perspective, SSL
encryption and decryption create an additional processing layer, beyond regular HTTP
processing. This layer includes the following two major CPU-intensive phases:
• SSL handshake
- After establishing a TCP connection, SSL creates a security context between
endpoints by using Public Key Interchange (PKI). This is known as an SSL
handshake. In terms of aggregate network traffic, an SSL handshake consumes
processing power that is proportional to the connection rate (measured in
connections per second).
• Encryption
- After a security context is established, an endpoint uses it to encrypt or decrypt
HTTP content. This processing is performed on each byte of HTTP data.
Therefore, it consumes processor cycles proportional to aggregate network
throughput (measured in megabits per second).
Decreasing the number of connections increases performance for secure communication
through SSL connections, as well as non-secure communication through simple TCP/IP
connections.
Under each server’s advanced logging configuration attributes, locate the following:
• Log File Severity Level: The minimum severity of log messages going to the server log
file. By default, all messages go to the log file.
• Standard Out Severity Level: The minimum severity of log messages going to the
standard out. Messages with a lower severity than the specified value will not be
published to standard out.
• Domain Log Severity Level: The minimum severity of log messages going to the
domain log from this server’s log broadcaster. Messages with a lower severity than the
specified value will not be published to the domain log.
By default, the HTTP subsystem keeps a log of all HTTP transactions in a text file. The default
location and rotation policy for HTTP access logs are the same as the server log. Disable the
HTTP access log from the Logging > HTTP tab. You can also tune HTTP logging for
individual Web applications using the XML descriptor weblogic.xml.
Finally, confirm that each JMS destination (topic or queue) does not enable message logging.
Select a destination and click its Configuration > Logging tab.
Log filters provide control over the log messages that are published. A filter uses custom logic
to evaluate the log message content, which you use to accept or reject a log message (for
example, to filter out messages of a certain severity level, from a particular subsystem, or
according to specified criteria). Only the log messages that satisfy the filter criteria are
published. You can create separate filters for the messages that each server instance writes
to its server log file, standard out, and memory buffer, or broadcasts to the domain-wide
message log.
1. Select the name of the active domain in the Domain Structure panel.
2. Click the Configuration > Log Filters tab. Click New. Enter a value to identify the filter in
the Name field and click Finish.
3. Edit the new filter. Enter the criteria for qualifying messages. You can click E dit to enter
or paste in an expression with the WLDF Query Language syntax, or you can click Add
Expression to construct an expression by using a set of dialog boxes.
A cluster:
Domain
• Is a logical group of managed servers
Cluster
from the same domain that run Clients
cooperatively Server
• Supports
availabilityfeatures
for webthat provide high
applications, web
Machine
A WebLogic Server cluster consists of one or more managed servers from the same domain
running simultaneously and working together to provide increased reliability and scalability. A
cluster appears to clients as one WebLogic Server instance. The server instances that
constitute a cluster can run on one machine or on multiple machines.
A cluster achieves high availability through the replication of services. Because of this
replication, failover is possible. When one server fails, a second server automatically can
resume operation where the first server left off.
Load balancing, the distribution of work across the cluster, ensures that each server in the
cluster helps carry the load.
Scalability is achieved because you can increase a cluster’s capacity by adding server
instances to the cluster, without making any architectural changes.
A cluster also assists in migration. After a system failure on one server, work can be
continued by moving the services that server provided to another server in the cluster (service
level migration), or by moving the entire server to a new hardware (whole server migration).
Once a cluster is created, configured servers can be added to it. A dynamic cluster is based
on a server template. A server template sets server attributes. Once a server template is
assigned to a cluster, servers based on the template are generated and added to the cluster.
Concept Description
Machine
Cluster
Server 1
Web App EJB
Code Code
Server 2
Web App EJB
Code Code
Cluster
Proxy
Server 3
Clients Web App EJB
Code Code Back-end
Systems
Server 4 and
Web App EJB Databases
Code Code
Firewall
Machine
The basic, single-tier cluster architecture has all W ebLogic Server application code in a single
tier. That single tier includes both web applications and Enterprise JavaBeans.
Remove the “EJB Code” box for systems that do not use EJBs.
Note: If web applications and EJBs are contained within the same deployment unit, then no
serialization/deserialization or network processing is required, thus increasing performance.
Machine
Cluster A
Server 1
Web App Machine
Code
Cluster B
Server 2 Server 5
Web App EJB
Code Code
Cluster
Proxy
Server 3 Server 6
Clients Web App EJB
Code Code Back-end
Systems
Server 4 and
Machine Databases
Web App
Code
Firewall
Machine
In the multi-tier cluster architecture, two separate WebLogic Server clusters are configured:
• Cluster A for the web application tier
• Cluster B to serve clustered EJBs
If your system does not use EJBs, you would not use the multi-tier cluster architecture in this
way. However, you could use it to load balance calls to JMS.
Note that calls between the web applications and EJBs are serialized and deserialized, which
along with accessing the network decrease performance.
Slowest
Server 1 Server 2 Network and
Web App EJB serialization
App.war Code processing
Server 1 Serialization
Web App EJB
App.war App.jar
processing
Server 1
EAR
App.ear NO network or
Web App EJB serialization
App.war App.jar processing
Fastest
Cluster
Architecture Advantages Disadvantages
Basic • Easier to administer • Cannot load balance
(single-tier) • Less network traffic EJB calls
• EJB calls are local (and therefore
faster)
Web server • Low cost (or free) • Only round-robin load balancing
with plug-in • You probably already have available
experience with the web server • Must configure the plug-in
Cluster Proxies are how clients interact with a web application cluster, whether they are
hardware or software based. You have two basic choices of cluster proxy: a web server using
a plug-in or a hardware load balancer (such as F5 BIG-IP).
Hardware load balancers must support a compatible passive or active cookie persistence
mechanism. Passive cookie persistence enables WebLogic Server to write a cookie
containing session information through the load balancer to the client. You can use certain
active cookie persistence mechanisms with WebLogic Server clusters, provided the load
balancer does not modify the WebLogic Server session cookie. If the load balancer's active
cookie persistence mechanism works by adding its own cookie to the client session, no
additional configuration is required to use the load balancer with a WebLogic Server cluster.
A WebLogic Server proxy plug-in is available for Netscape Enterprise Server, Apache HTTP
Server, Microsoft Internet Information Server (IIS), and Oracle HTTP Server (which is based
on Apache). These plug-ins provide round-robin load balancing to the servers in the cluster.
They use the W ebLogic Server session cookie information to route requests to the server that
has a client’s session data.
A proxy plug-in:
• Load balances client requests to clustered WebLogic
Server instances in a round-robin fashion
• Avoids routing requests to failed servers in the cluster
Cluster
Server 1
Web Server Server 2
Plug-in Server 3
Server 4
Clients
Passive cookie
Passive cookie persistence enables the W ebLogic Server to write a cookie containing session
parameter information through the load balancer to the client. When using some hardware
load balancers, you must configure the passive cookie persistence mechanism to avoid
overwriting the WebLogic Server cookie that tracks primary and secondary servers used for
in-memory replication. Specifically, you must set the following values:
• String offset value to the Session ID value plus 1 byte for the delimiter character
• String length to 10 bytes
Active cookie
Active cookie persistence is supported as long as the mechanism does not overwrite or
modify the WebLogic HTTP session cookie. In this case, no additional configuration is
required.
SSL persistence
SSL persistence performs all encryption and decryption of data between clients and the
cluster and uses a plain text cookie on the client to maintain an association between the client
and a server in the cluster.
OHS is based on the Apache web server. OHS supports single sign-on, clustered deployment
and high availability, and Web Cache.
Configuration of Oracle HTTP Server is specified through directives in configuration files in
the same manner as with Apache HTTP Server.
A mod_wl_ohs module is available in OHS. This module enables you to integrate your
WebLogic Server environment with OHS immediately after the configuration of the OHS
instance and the domains.
OHS directories are divided between the Oracle home and the Oracle instance. The Oracle
home directories are read-only, and contain the Oracle Fusion Middleware binaries. The
Oracle instance directories contain the modules, applications, and logs for OHS. Each OHS
component has a root configuration directory found at
<instance>/config/OHS/<component>, which includes the W LS plug-in configuration
file, mod_wl_ohs.conf. Similarly, each component’s log files are found at
<instance>/diagnostics/logs/OHS/<component>.
• Pages-served performance
• Flow of connections to the servers
• Management and configuration tools
• Security
• Load-balancing algorithms
• Other features
Passive cookie
Passive cookie persistence enables the W ebLogic Server to write a cookie containing session
parameter information through the load balancer to the client. When using some hardware
load balancers, you must configure the passive cookie persistence mechanism to avoid
overwriting the WebLogic Server cookie that tracks primary and secondary servers used for
in-memory replication. Specifically, you must set the following values:
• String offset value to the Session ID value plus 1 byte for the delimiter character
• String length to 10 bytes
Active cookie
Active cookie persistence is supported as long as the mechanism does not overwrite or
modify the WebLogic HTTP session cookie. In this case, no additional configuration is
required.
SSL persistence
SSL persistence performs all encryption and decryption of data between clients and the
cluster and uses a plain text cookie on the client to maintain an association between the client
and a server in the cluster.
– Random
• You should skip dead servers in a cluster, thereby
improving response times.
• Use a hardware load balancer directly in front of a
WebLogic Server cluster to minimize the number of hops.
• Hardware load balancers may also be able to absorb
SSL-processing load
Using a hardware load balancer directly in front of a W ebLogic Server cluster results in a
single network hop from the load balancer to a WebLogic Server. This provides better
performance than placing the load balancer in front of a farm of third-party proxy web servers,
which require the standard two hops:
• One from the load balancer to the web server
• The other from the web server to a WebLogic Server
Load balancers often provide SSL acceleration that offloads the SSL processing from the
application server to the dedicated SSL accelerator. This can also significantly improve
performance by decreasing the amount of time required to process secure transactions.
Web application components such as servlets and JSPs maintain data on behalf of clients by
using an HttpSession instance that is available on a per-client basis. To provide high
availability of web applications, shared access to a single HttpSession object must be
provided. HttpSession objects can be replicated within the WebLogic Server by storing
their data via in-memory replication, file system persistence, database persistence, or
Coherence*Web persistence.
Cluster
• The WebLogic Server (WLS)
can replicate: Server 1
– HttpSession objects Primary
– Stateful session EJBs
Server 2
• Session objects(primary
on two servers exist in and
memory
backup). Secondary
• Backup:
Server 3
– Server determined by replication
Secondary
group or machine definition
– Object created immediately after
Server 4
the primary object is created
Primary
• Primary failure makes the backup
object the primary object.
Using in-memory replication, WebLogic Server copies session state from one server instance
to another. The primary server stores the primary session state (the primary server is the
server to which the client is connected when a session is first created). A replica of the
session state is stored on another instance of WebLogic Server in the cluster (the secondary
server). The replica is kept up-to-date so that the data there can be used if the primary server
fails.
By default, session replication is synchronous. The asynchronous option replicates data in
batches to improve cluster performance.
In the event of a failure of the primary object, the backup object will be promoted to the
primary object for all future requests. When a failover situation occurs, another backup object
will be created. This is ideal because the replication of object data has to occur only between
the primary and backup objects (rather than the entire cluster).
The graphic shows that each primary server in the cluster is backed up to another single
server in the cluster.
File System
Server
Cluster
Web App
Proxy Code
Clients
Server
Web App
Code
sessions. Servlet 1
Whenever a servlet creates or uses a session object, the servlet stores the session data
persistently in the database. When a subsequent client request enters the cluster, any server
in the cluster can handle the request. Each server in the cluster has identical access to the
persistent store where it can look up the information needed to satisfy the client’s request.
This technique provides for good failover capability because any server in the cluster can
resolve a client’s request, but there is a significant performance reduction due to the many
database synchronizations required in a large web-based system.
Session persistence is not used for storing long-term data between sessions. That is, you
should not rely on a session still being active when a client returns to a site at some later date.
Instead, your application should record long-term or important information in a database.
You should not attempt to store long-term or limited-term client data in a session. Instead,
your application should create and set its own cookies on the browser. Examples of this
include an auto-login feature where the cookie lives for a long period or an auto-logout feature
where the cookie expires after a short period of time. Here, you should not attempt to use
HTTP sessions; instead you should write your own application-specific logic.
The graphic shows that in persistent JDBC replication, each server in the cluster is connected
to a database using a JDBC connection pool. The HttpSession state is stored in the
database.
Grid
Replicated data
Application Cache Server provides a backup
Network for failover.
Distributed cache:
Near cache: In-memory cached
Locally cached objects objects across JVMs
Partitioning refers to the ability of Coherence to load-balance data storage, access, and
management across all the servers in the cluster. For example, when using Coherence data
partitioning, if there are four servers in a cluster, each will manage 25% of the data. And if
another server is added, each server will dynamically adjust so that the five servers will
manage 20% of the data. This data load balancing will occur without any application
interruption and without any lost data or operations. Similarly, if one of those five servers were
to fail, each of the remaining four servers would readjust to managing 25% of the data. Once
again, there is no data loss, including the 20% of the data that was being managed on the
failed server.
While the partitioning feature dynamically load balances data evenly across the entire server
cluster, replication ensures that a desired set of data is always available and up-to-date at all
times in the cluster. Replication allows operations running on any server to obtain the data
that they need locally, at basically no cost, because that data has already been replicated to
that server. The only downside of partitioning is that it introduces latency for data access, and
in most applications the data access rate far outweighs the data modification rate. To
eliminate the latency associated with partitioned data access, Coherence can employ “near
caching.” Frequently and recently used data from the partitioned cache are maintained on the
specific servers that are accessing that data within a near cache, and this local data is kept
up-to-date by using event-based invalidation.
– Improve server
connections performance
among by sharing
multiple users database
accessing the Web
application
Application server
Connection pool
Connection
available
RDBMS
Java Connection
application in use
Database
One of the advantages of using connection pools over direct connections is that the
connections already exist when applications want to connect to a database. This saves
applications the overhead of creating connections. Also the middle tier software (WLS) can
apply load balancing by assigning connections to applications using a database, and then
releasing and making them available for other applications when they are no longer in use.
Load balancing can also include dynamic growing and shrinking of the number of connections
in a connection pool to adapt to changing load conditions. Connection pools add other
advantages such as the potential for applying security to a connection.
The graphic shows that the application server hosts the connection pool and that applications
use the pools on an as-needed basis.
Each JDBC data source has a pool of JDBC connections that are created when the data
source is deployed or at server startup. Applications use a connection from the pool and then
return it when they have finished using the connection. Connection pooling enhances
performance by eliminating the costly task of creating database connections for the
application.
Creating a database connection is a relatively expensive process in any environment.
Typically, a connection pool starts with a small number of connections. As client demand for
more connections grows, there may not be enough in the pool to satisfy the requests. The
WebLogic Server creates additional connections and adds them to the pool until the
maximum pool size is reached.
One way to avoid connection-creation delays for clients using the server is to initialize all
connections at server startup, rather than on demand as clients need them. Set the initial
number of connections equal to the maximum number of connections on the Connection Pool
tab of your data source configuration. However, you still need to determine the optimal value
for the Maximum Capacity as part of your preproduction performance testing.
• Tune accordingly:
– Maximum Capacity
– Connection Reserve Timeout (default: 10 sec)
JDBC application performance gains are determined by how the application is designed. The
number and location of clients, size, and structure of database management system (DBMS)
tables and indexes, and the number and types of queries affect application performance.
Whenever possible, collect a set of data operations and submit an update transaction in one
statement. This approach results in better performance than using separate statements and
commits.
A simple way to boost JDBC application performance and avoid wasting resources:
• JNDI lookups are relatively expensive. So caching an object that requires a lookup in
client code or application code avoids incurring additional performance cost.
• When client or application code has a connection, maximize the reuse of this connection
rather than closing and reacquiring a new connection. Although acquiring and returning
an existing creation is much less expensive than creating a new one, excessive
acquisitions and returns to pools create contention in the connection pool and degrades
application performance.
• Do not hold connections any longer than is necessary to achieve the work needed.
Getting a connection once, completing all necessary work, and returning it as soon as
possible provides the best balance for overall performance.
• Connections can
using the Test also be tested
Frequency periodically for validity by
parameter.
To access the JDBC connection pool parameters click Configuration > Connection Pool >
Advanced after having selected the JDBC data source you want to modify.
To make sure that the database connections in a data source remain healthy, you should
periodically test the connections. The WebLogic Server provides automatic testing that you
configure with options on the data source so that the WebLogic Server makes sure that
database connections remain healthy. To configure automatic testing options for a data
source, you set the following options either through the Administration Console or through
WebLogic Scripting Tool (WLST) by using JDBCConnectionPoolParamsBean:
• Test Reserved Connections: Select this option to test each connection before
assigning to a client. This may add a slight delay to the request, but it guarantees that
the connection is healthy. You must also set a Test Table Name.
- When Test Connections On Reserve is enabled, the WebLogic Server tests the
connection by using the query specified in Test Table Name when your application
requests a connection from the data source.
- Testing reserved connections can cause a delay in satisfying connection requests,
but it makes sure that the connection is viable when the application gets the
connection. You can minimize the impact of testing-reserved connections by
tuning Seconds to Trust an Idle Pool Connection.
The screenshot shows how to configure the pool shrink frequency by using the Administration
Console.
Row Prefetch Enabled: Enables multiple rows to be “prefetched” (that is, sent from the
server to the client) in one server access. When an external client accesses a database using
JDBC through the WebLogic Server, row prefetching improves performance by fetching
multiple rows from the server to the client in one server access. The WebLogic Server ignores
this setting and does not use row prefetching when the client and the WebLogic Server are in
the same JVM.
Row Prefetch Size: Specifies, if row prefetching is enabled, the number of result set rows to
prefetch for a client. The optimal prefetch size depends on the particulars of the query. In
general, increasing this number will increase performance, until a particular value is reached.
At that point, further increases do not result in any significant performance increase. Very
rarely will increased performance result from exceeding 100 rows.
Minimum value: 2
Maximum value: 65536
The screenshot shows how to configure Row Prefetch by using the Administration Console.
• The prepared
cacheable andstatements and callable
improve overall statements
performance are
through
reuse.
• The statement cache type determines how the cache is
refreshed:
– LRU: Replace least recently used
– FIXED: No replacement
– Callable statements
• Tune according to hit/miss ratio.
To minimize the time it takes for an application to reserve a database connection from a data
source and to eliminate contention between threads for a database connection, you can
enable the Pinned-To-Thread property in the connection properties.
When Pinned-To-Thread is enabled, the WebLogic Server pins a database connection from
the data source to an execution thread the first time an application uses the thread to reserve
a connection. When the application finishes using the connection and calls
connection.close(), which otherwise returns the connection to the data source, the
WebLogic Server keeps the connection with the execute thread and does not return it to the
data source. When an application subsequently requests a connection using the same
execute thread, the WebLogic Server provides the connection already reserved by the thread.
There is no locking contention on the data source that occurs when multiple threads attempt
to reserve a connection at the same time and there is no contention for threads that attempt to
reserve the same connection from a limited number of database connections.
In this release, the Pinned-To-Thread feature does not work with multidata sources or Oracle
RAC. These features rely on the ability to return a connection to the connection pool and
reacquire it if there is a connection failure or if a connection identity does not match.
Transactions require processing overhead, which can reduce your system’s performance
when compared to a transaction-free (but more easily corruptible) application. Transactions
are a lot of work for a database, and databases by default maintain many kinds of resources
to ensure that ACID properties apply to a transaction.
Combine transactions by moving multiple operations into a single transaction.
By default, JDBC connections work in auto-commit mode, which means that every operation
sent to the database automatically executes as a separate transaction. Turning off auto-
commit and explicitly defining transaction boundaries around multiple database calls can
improve performance. To turn off auto-commit, use the
Connection.setAutoCommit(false) command.
The JDBC API also provides aConnection.getAuto Commit() method that returns the
current auto-commit mode. W hen you turn off auto-commit, you will need to use the
transaction demarcation methods ofConnection.start(), Connection.commit() and
Connection.rollback().
Non-
Dirty Phantom
Level repeatable
Read Read
Read
READ
Permitted Permitted Permitted
UNCOMMITTED
READ
COMMITTED X Permitted Permitted
REPEATABLE
READ X X Permitted
SERIALIZABLE
X X X
Dirty read: You are permitted to read uncommitted, or dirty , data. You can achieve this effect
by just opening an OS file that someone else is writing and reading whatever data happens to
be there. Data integrity is compromised, foreign keys are violated, and unique constraints are
ignored.
Non-repeatable read: This simply means that if you read a row at time T1 and try to reread
that row at time T2, the row may have changed. It may have disappeared, it may have been
updated, and so on.
Phantom read: This means that if you execute a query at time T1 and re-execute it at time
T2, additional rows may have been added to the database, which may affect your results.
This differs from a non-repeatable read in that with a phantom read, data you already read
hasn't been changed, but instead, more data satisfies your query criteria than before.
e Isolation Level
c
n TRANSACTION_SERIALIZABLE D
a a
m ta
r TRANSACTION_REPEATABLE_READ
o In
rf te
e TRANSACTION_READ_COMMITTED g
P r
it
TRANSACTION_READ_UNCOMMITTED y
SDP was srcinally defined by the Software Working Group (SWG) of the InfiniBand Trade
Association. Initially designed for InfiniBand (IB), SDP has now been redefined as a transport-
agnostic protocol for RDMA network fabrics.
SDP defines a standard wire protocol over an RDMA fabric to support stream sockets
(SOCK_STREAM). SDP uses various RDMA network features for high-performance zero-
copy data transfers. The purpose of the Sockets Direct Protocol is to provide an RDMA-
accelerated alternative to the TCP protocol on IP. The goal is to do this in a manner which is
transparent to the application.
• Number of processes
– It includes simultaneous users and Oracle background
processes.
– The default setting (150) is usually too low to accommodate
a large number of users.
• System Global Area (SGA)
– It contains data and control information for each instance.
– It is critical to performance.
– Oracle 11g introduced a new feature called Automatic
Memory Management (AMM), which allows for a simplified
and dynamic configuration of the SGA.
• Maximum opened cursor
– It should be increased if you are using JDBC statement
caching.
You should refer to Oracle Database 2 Day + Performance Tuning Guide 11g Release 2
(11.2) documentation for more detailed information about tuning the Oracle database. The
few parameters mentioned here are commonly tuned in an Oracle WebLogic Server
environment.
• PGA_AGGREGATE_TARGET
– It dictates performance of large sorts.
– It should be used to allow Oracle to automatically adjust and
size the memory needed for expensive operations like group-
by, hash-join, bitmap merge, etc.
– If Automatic Memory Management (AMM) has been set,
PGA_AGGREGATE_TARGET is redundant.
– Moving forward, AMM should be used in preference to
manual memory configuration.
OLTP applications tend to perform better with a smaller DB_BLOCK_SIZE (2048 or 4096
bytes) while data warehouses usually set this parameters to larger values (16 or even 32 Kb)
Setting PGA_AGGREGATE_TARGET to a nonzero value has the effect of automatically
setting the WORKAREA_SIZE_POLICY parameter to AUTO. This means that SQL working
areas used by memory-intensive SQL operators such as sort, group-by, hash-join, bitmap
merge, and bitmap create will be automatically sized. The memory allocated for
PGA_AGGREGATE_TARGET is not subtracted fromthe memory allocated for theSystem
Global Area (SGA)
Best practice: Use Automatic Memory Management (AMM) – Automatic memory
management is configured using two Oracle RDBMS initialization parameters:
MEMORY_TARGET: The amount of shared memory available for Oracle to use when
dynamically controlling the SGA and PGA. This parameter is dynamic, so the total amount of
memory available to Oracle can be increased or decreased, provided it does not exceed the
MEMORY_MAX_TARGET limit. The default value is "0".
Client Server
Client
Client
WebLogic uses a single thread pool, in which all types of work are executed. The WebLogic
Server prioritizes work based on rules that you define, and run-time metrics, including the
actual time it takes to execute a request and the rate at which requests are entering and
leaving the pool.
The common thread pool changes its size automatically to maximize throughput. The
incoming request queue monitors throughput over time and, based on history, determines
whether to adjust the thread count. For example, if historical throughput statistics indicate that
a higher thread count increased throughput, WebLogic increases the thread count. Similarly, if
statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the
thread count. This new strategy makes it easier for administrators to allocate processing
resources and manage performance, avoiding the effort and complexity involved in
configuring, monitoring, and tuning custom execution queues.
Select a server and click its Monitoring > Threads tab. The first table provides general
information about the status of the thread pool. The second table provides information about
individual threads. The available columns in the first table include:
• Execute Thread Tot al Count: The total number of threads in the pool
• Execute Thread Idle Count: The number of idle threads in the pool. This count does
not include standby threads and stuck threads. The count indicates threads that are
ready to pick up new work when it arrives.
• Pending User Request Count: The number of pending user requests in the priority
queue. The priority queue contains requests from internal subsystems and users. This is
just the count of all user requests.
• Hogging Thread Count: Returns the threads that are being hogged by a request right
now. These threads will either be declared as stuck after the configured timeout or will
return to the pool before that. The self-tuning mechanism will backfill if necessary.
The second table on the server’s Monitoring > Threads tab provides the status and statistics
for individual threads, including:
• Total Requests: The number of requests that have been processed by the thread
• Current Request: A String representation of the request this thread is currently
processing
• Transaction: The XA transaction on whose behalf the execute thread is currently
working
• User: The name associated with this thread
• Idle: Returns the value “true” if the execute thread has no work assigned to it
• Stuck: Returns “true” if the execute thread is being hogged by a request for much more
than the normal execution time as observed by the scheduler automatically. If this
thread is still busy after the stuck thread max time, it is declared as stuck.
WebLogic allows you to configure how your application prioritizes the execution of its work.
Based on rules that you define and by monitoring actual runtime performance, WebLogic can
optimize the performance of your application and maintain SLAs. You tune the thread
utilization of a server instance by defining rules and constraints for your application by
defining a work manager and applying it either globally to WebLogic domain or to a specific
application component. Each distinct SLA requirement needs a unique work manager.
You can associate one set of scheduling guidelines for one application, and another set of
guidelines for other applications. At run time, WebLogic uses these guidelines to assign
pending work and queued requests to execution threads.
You can define multiple work managers. The appropriate number depends on how many
distinct demand profiles exist across the applications you host on WebLogic.
You can configure work managers at the domain level, application level, and module level.
To handle thread management and perform self-tuning, WebLogic implements a default work
manager. This work manager is used by an application when no other work managers are
specified in the application’s deployment descriptors. In many situations, the default work
manager may be sufficient for most application requirements. WebLogic’s thread-handling
algorithms assign to each application its own fair share by default. Applications are given
equal priority for threads and are prevented from monopolizing them.
You can override the behavior of the default work manager by creating and configuring a
global work manager called “default.” This enables you to control the default thread-handling
behavior of W ebLogic.
Application
Configured in
config.xml
WM2
You can create global work managers that are available to all applications and modules
deployed on a server in the WebLogic administration console and in config.xml. An
application uses a globally defined work manager as a template. Each application creates its
own instance that handles the work associated with that application and separates that work
from other applications. This separation is used to handle traffic directed to two applications
that are using the same dispatch policy. Handling each application’s work separately allows
an application to be shut down without affecting the thread management of another
application. Although each application implements its own work manager instance, the
underlying components are shared.
In addition to globally scoped work managers, you can also create work managers that are
available only to a specific application or module. You can define application-scoped work
managers in the WebLogic administration console and in the following descriptors:
weblogic-application.xml, weblogic-ejb-jar.xml, and weblogic.xml. If you do
not explicitly assign a work manager to an application, it uses the default work manager.
Constraint A
Request Class Work Manager
Constraint B
A request class expresses a scheduling guideline that WebLogic uses to allocate threads to
requests. Request classes help ensure that high-priority work is scheduled before less
important work, even if the high-priority work is submitted after the low-priority work.
WebLogic takes into account how long it takes for requests to each module to complete.
A constraint defines the minimum and maximum number of threads allocated to execute
requests and the total number of requests that can be queued or executed before WebLogic
begins rejecting requests.
In response to stuck threads, you can define an error-handing policy that shuts down the work
manager, moves the application into administration mode, or marks the entire server instance
as failed.
constraint
• Assigning each work manager to different applications
• Comparing work managers under load
JavaServer Page (JSP) is a JavaSoft standard specification for combining Java with HTML to
provide dynamic content on web pages. JSPs are more convenient to write than HTTP
servlets because they allow you to embed the Java directly into your HTML page layout. JSPs
are part of the Java Enterprise Platform.
JSPs are meant to be the Web’s entry point into the Java Platform for the Enterprise (JPE).
JSPs are capable of using the JavaBean methods, and therefore provide access to EJBs and
databases.
The syntax for using JSPs is relatively simple, especially if you are already familiar with HTML
and Java. As you will see, most of the Java code and HTML parts in your JSP are combined
to form one large service method for a servlet class.
The graphic in the slide shows the relationship between the JSP code and the HTML
rendered on a browser.
• Execution of JSP
JSPServlet translates
myServlet.jsp _myservlet.java
No changes
JSPServlet
since last
translation compiles
HTML _myservlet.class
JSPServlet
loads/executes
When a URL is provided to the WebLogic Server that maps to an underlying JSP, that JSP
must be executed. A special W LS servlet, the JSPServlet, performs the translation and
execution. First, the JSP is examined to see whether it has been previously translated into its
underlying servlet representation. If not, the JSP is compiled and then executed to service the
request. If the JSP has been previously executed, it is precompiled and the source is
examined. If the code is determined to be newer than the previously compiled version, the
JSP is recompiled and then executed. In either case, the servlet representation of the
requested JSP is invoked by the web container to process the given request.
The graphic shows that a JSP is compiled into a servlet class on its first invocation. From that
point onward, every request is redirected to the compiled servlet class.
By deploying precompiled JSPs, the first access to the JSPs can be performed faster
because the server does not have to spend time in translation and compilation. Also, because
the compiled JSPs are loaded into memory, and uncompiled JSPs need not be loaded into
memory, the memory consumption is reduced. Accordingly, the memory management effort is
also reduced.
The appc compiler, while compiling EJBs and JSPs, also validates the deployment
descriptors The appc compiler offers the following benefits:
• The flexibility of compiling an entire application, rather than compiling individual modules
separately and combining them into an EAR.
• Validation checks all modules and validates application-level deployment descriptors
against the various modules. Without appc, a user had to extract the individual
components of an EAR and manually execute the appropriate compiler (jspc or ejbc)
to prepare the module for deployment. appc automates this process and makes
additional pre-deployment validation checks that were not previously possible.
• It is easy to identify and correct errors that appc produces. If an error occurs while
running appc from the command line,appc exits with an error message. By contrast, if
you defer compilation to the time of deployment and a compilation error occurs, the
server fails the deployment and goes on with its work. To determine why deployment
failed, you must examine the server output, fix the problem, and then redeploy.
• By running appc before deployment, you potentially reduce the number of time a bean
is compiled. For example, if you deploy a JAR file to a cluster of three servers, the JAR
file is copied to each of the three servers for deployment. If the JAR file was not
precompiled, each of the three servers will have to compile the file during deployment.
<jsp-descriptor>
<precompile>true</precompile>
</jsp-descriptor>
When using the precompile parameter in weblogic.xml, recompilation of JSPs will occur
each time the server restarts and when you target additional servers.
The default value for precompile, if not specified, is false.
The server compiles JSP files at first deployment. When the server starts subsequently, the
server checks the timestamps of JSP and compiled servlets. If none has changed, then the
compilation is skipped and the server starts up quite fast. Consider this case where JSPs
names have multiple case, such asshowAcccount.jsp
• When a file named showAccount.jsp is compiled, the JSP compiler generates a
servlet __showaccount.class(all lowercase characters) by default, but the stale
checker searches for __showAccount.class (with a capital A in the name). This can
be a concern in UNIX environments, where the stale checker doesnot find __
showAccount.class and recompiles all such files again. This can cause delays at
startup.
• To overcome this, you can use -Dweblogic.jsp.windows.caseSensitive=true.
If you use this switch, then the stale checker finds the __showAccount.class
because the compiler generated this case-sensitive class name.
You will not see this difference for filenames that are already all lowercase, such as
welcome.jsp.
The default value for keepgenerated is false. Unless this parameter is set to true, the
intermediate Java files are deleted after they are compiled.
A snippet from weblogic.xml:
<jsp-descriptor>
<keepgenerated>false</keepgenerated>
</jsp-descriptor>
JSPServlet
page translates
myServlet.jsp check _myservlet.java
HTML _myservlet.class
JSPServlet loads/executes
The graphic in the slide shows that the JSP is compiled into a servlet based on whether the
JSP has been changed or not. The server will determine whether the JSP should be
recompiled based on the page check.
The page-check-seconds attribute sets the interval at which the WebLogic Server checks
to see whether JSP files have changed and need recompiling. Dependencies are also
checked and recursively reloaded if changed.
• The value –1 means never check the pages. This is the default value in a production
environment.
• The value 0 means always check the pages.
• The value 1 means check the pages every second. This is the default value in a
development environment.
In a production environment, where changes to a JSP are rare, it may be best to set the
attribute to –1. In rare cases, where it does require an occasional compilation or change, set
this value at a reasonably high value such as 3600, according to your tuning requirements.
When set to true, debugging information is printed out to the browser, the command prompt,
and the WebLogic Server log file. The default value for verbose if not specified is true.
Web servers provide a hosting environment that is optimized for delivering static content and
files over HTTP. They typically support common server features such as single sign-on,
access control, and high availability. It is also common for web servers to provide an
execution environment for simple applications that generate dynamic content using languages
such as PERL.
The WebLogic Server is in fact a web server, because it can provide these services as well.
However, the WebLogic Server is optimized for processing Java application requests and for
serving dynamic web content generated from servlets and JSPs. Therefore, if your web
application includes a significant number of static file resources such as HTML documents,
images, and JavaScript libraries, you may achieve greater performance and scalability by
offloading these static resources from the WebLogic Server to one or more dedicated web
servers.
A larger session timeout value means that the session object stays in memory for a longer
period. The size of the session object and the session timeout value can impact performance,
if there are a large number of users.
The default value for the session timeout if not specified is 3,600 seconds.
The WebLogic Server does periodic checks for timed-out and invalid sessions. This is done to
delete old sessions and free up memory. Theinvalidation-interval-secsparameter
controls the time between the memory cleanup.
The default value for invalidation-interval-secsif not specified is 60 seconds.
• If there
false asisthe
novalue
need for
forthe
the session
HttpSession in a JSP, assign
attribute.
– Avoids the unnecessary creation of session objects
– Reduces overhead on memory and the garbage collector
– Could increase performance
• An example use of directives:
<%@ page session="false"%>
If you do not specify the attribute session as false, then by default a session object is created.
Consider the case that customer has completed a session, but then inadvertently tries to
connect back to the completed session, then the JSP indicates that the session is no longer
valid.
Oracle provides three specialized JSP tags that you can use in
your JSPs:
• cache: Enables caching the work that is done within the
body of the tag
• process : EnablesJSPs
parameter–based you to control the flow of query
• repeat: Enables you to iterate over many different types
of sets, including Enumerations, Iterators, Collections, and
Arrays of Objects
Oracle provides three specialized JSP tags that you can use in your JSPs: cache, repeat,
and process. These tags are packaged in the weblogic-tags.jar tag library JAR file.
This JAR file contains classes for the tags and a tag library descriptor (TLD). To use these
tags in your JSP:
• Copy the weblogic-tags.jar file from the ext directory of your WebLogic Server
installation to the WEB-INF/lib directory of the web application containing the JSPs.
• Reference this tag library descriptor in the <taglib> element of the Java EE standard
web application deployment descriptor, web.xml. For example:
<taglib>
<taglib-uri>weblogic-tags.tld</taglib-uri>
<taglib-location>
/WEB-INF/lib/weblogic-tags.jar
</taglib-location>
</taglib>
• Reference the tag library in your JSP with the taglib directive. For example:
<%@ taglib uri="weblogic-tags.tld" prefix="wl" %>
<wl:cache name="holidaycache"
key="parameter.holidaytable"scope="application">
// Retrieve Holidays and output it to the page
</wl:cache>
The cache tag enables caching the work that is done within the body of the tag. It supports
both output (transform) data and input (calculated) data. Output caching refers to the content
that is generated by the code within the tag. Input caching refers to the values to which
variables are set by the code within the tag. Output caching is useful when the final form of
the content is the important thing to cache. Input caching is important when the view of the
data can vary independently of the data calculated within the tag. If one client is already
recalculating the contents of a cache and another client requests the same content, it does
not wait for the completion of the recalculation; instead, it shows whatever information is
already in the cache. This is to ensure that the web site does not come to a halt because a
cache is being recalculated. Additionally, the async attribute means that no one, not even the
user that initiates the cache recalculation, waits. You can force the refresh of a cache by
setting the _cache_refresh object to true in the scope that you want affected. For example,
to refresh a cache at session scope, specify the following:
<% request.setAttribute("_cache_refresh", "true"); %>
If you want all caches to be refreshed, set the cache to the application scope.
Flushing a cache forces the cached values to be erased; the next time the cache is accessed,
the values are recalculated. To flush a cache, set its flush attribute to true.
Since any values explicitly specified in weblogic.xml override the defaults, be careful when
moving an application from Development to Production since frequent checking for changes
can cause poor performance due to the disk I/O required to look for changes.
Calling flush() or close() (which does not actually close but calls flush()) can force WLS to
chunked transfer encoding if the content length has not been set prior to the call. Although
chunked transfer encoding works fine, there is additional overhead to using it versus the
normal response encoding.
Client 1
Client 2
Pool of
Client 3 three beans
Client 4
Blocked
Client 5
Application server
Stateless session beans are maintained in memory and provide nonconversational services.
They do not maintain state on behalf of clients. Accordingly, they do not need to be
maintained over server crash.
The EJB container can pool stateless session EJBs that can be used or reused by different
clients. However, no two clients can access the same EJB instance at the same time.
An application server container can pool stateless session EJBs in the server and make the
beans reusable by different clients. Even though multiple clients might request the use of a
stateless session EJB, the container is not required to create an instance for each client. The
container can optimize the number of instances that it maintains to make the server more
scalable.
The EJB specification mandates that a session EJB can be accessed only by one client at
any time. This means that if the container created only one EJB instance and there were 10
clients requesting the use of that instance, only one client would be allowed to have access to
the instance at any time. The other nine clients would have to block and wait for the first client
to finish using the stateless session EJB. So a container may create multiple instances so that
multiple clients can concurrently have their requests handled.
Note that the clients cannot hold on to a bean forever. There is a timeout period (RMI request
timeout) after which the method call fails and the bean becomes free again.
JMX).
• A high pool miss ratio indicates an improperly tuned pool
where instances of specific beans are not found in the pool
at runtime.
WLS console:
• Look for Monitoring->EJBs->Stateless
– "Access Total Count" and "Miss Total Count"
Method complete
Free pool
EJBbusy EJBinactivated
Client
request
<initial-beans-in-free-pool>
EJB does not exist
This graphic shows the WebLogic Server free pool and the processes by which stateless
EJBs enter and leave the pool. “EJB does not exist,” “EJB busy,” and “EJB inactivated”
represent the states of the EJB from the perspective of the WebLogic Server.
On startup, the WebLogic Server automatically creates and populates the free pool with the
quantity of instances that you specify in the bean’s initial-beans-in-free-pool
deployment element in the weblogic-ejb-jar.xml file. By default, initial-beans-in-
free-pool is set to 0.
If you configure a pool, the W ebLogic Server services method calls with an EJB instance from
the free pool, if one is available. The EJB remains active for the duration of the client’s
method call. After the method completes, the EJB instance is returned to the free pool.
Because the WebLogic Server unbinds stateless session beans from clients after each
method call, the actual bean class instance that a client uses may be different from invocation
to invocation. If all instances of an EJB class are active and max-beans-in-free-pool
has been reached, new clients requesting the EJB class will be blocked until an active EJB
completes a method
minutes elapse), call. If the transaction
the WebLogic times
Server throws out (or, for non-transactional
a RemoteException calls,
for a remote if fiveor an
client
EJBException for a local client.
Note: The maximum size of the free pool is limited by the value of the max-beans-in-
free-pool element, available memory, or the number of execute threads.
When a client calls a method on a stateless session EJB, the WebLogic Server obtains an
instance from the free pool. The EJB remains active for the duration of the client’s method
call. After the method completes, the EJB instance is returned to the free pool. Because the
WebLogic Server unbinds stateless session beans from clients after each method call, the
actual bean class instance that a client uses might be different from invocation to invocation.
By default, no stateless session EJB instances exists in the WebLogic Server at startup time.
As clients access individual beans, the WebLogic Server initializes new instances of the EJB.
Optionally, you can set theinitial-beans-in-free-poolelement in weblogic-ejb-
jar.xml to automatically create EJB instances in the free pool during startup. This can
improve initial response time when clients access EJBs because initial client requests can be
satisfied by activating the bean from the free pool (rather than initializing the bean and then
activating it). By default, initial-beans-in-free-pool is set to 0.
The maximum size of the free pool is limited by available memory, or the value of themax-
beans-in-free-pool element.
If all instances of an EJB class are active and max-beans-in-free-poolhas been
reached, new clients requesting the EJB class are blocked until an active EJB completes a
method call. If the transaction times out (or, for non-transactional calls, if five minutes
elapses), the WebLogic Server throws a RemoteException.
Container
Client
sends
JMS destination
Message-driven beans were introduced as part of the EJB 2.0 specification. Message-driven
beans are asynchronous components that decouple (break apart) clients from the beans that
they use.
Synchronous components implement a block-and-wait behavior. For instance, when a client
invokes a method on a stateless session bean, the client application blocks and waits for the
bean to complete execution. The client application cannot continue until the bean has
completed. In an asynchronous model, a client can invoke a bean and then not wait for the
method to complete before continuing to other activities.
JMS clients publish messages to JMS destinations that are hosted on application servers.
Publishing messages is a very lightweight activity for clients. After publishing a message, a
client is not concerned with the routing, direction, or delivery of the message to the receiver.
The JMS server handles the delivery of the message independently of the client’s operations.
Message-driven beans are special EJBs designed to receive messages sent from JMS
clients.
The graphic in the slide shows a client putting messages into a JMS destination. The
messages are consumed by MDBs.
With J2EE 6, EJB methods can be invoked asynchronously, alleviating the need to resort to
MDB just to obtain asynchronous behavior from EJBs.
You can define the initial and maximum sizes of the message-driven bean pool in the
weblogic-ejb-jar.xmldeployment descriptor.
The idle-timeout-seconds parameter defines the maximum time that an EJB should
remain idle in the free pool before it is removed. After this time has elapsed, WebLogic Server
removes the bean instance from the free pool so long as doing so will not cause the number
of beans in the pool to fall below the number specified in initial-beans-in-free-pool.
Both stateless session beans and message-driven beans can use idle-timeout-seconds
to remove unused bean instances down to initial-beans-in-free-pool. This can help reclaim
memory from inactive sessions for active sessions.
The WebLogic Server provides a mechanism for grouping onMessage() calls together as a
single transaction. This mechanism can help increase database performance of an EJB
application by grouping all the transactions into a single I/O request. Grouping transactions
requires fewer transaction logs.
You can enable MDB transaction batching by defining the max-messages-in-
transaction element of the weblogic-ejb-jar.xmldeployment descriptor. The max-
messages-in-transactionelement defines the batch size that the WebLogic Server
uses to process onMessage() transactions. However, increasing the batch size can
increase latency. You should start with a small value (for example, 5). You can increase this
value as your application performance allows.
When using MDB batching, more messages are processed per transaction. This may cause
more transactions to time out because more work is being performed in each transaction. You
can increase the transaction timeout by increasing the value of the trans-timeout-
seconds attribute of weblogic-ejb-jar.xml.
RuntimeException
acknowledgement. to prevent message
– EJB spec requires destroying the MDB instance
– Use weblogic.ejb.NonDestructiveRuntimeException to
prevent WLS from destroying the MDB instance
• Use Foreign JMS Server for remote destinations
WebLogic Server has the concept of a Foreign JMS Server that allows you to specify the
JNDI information for remote Connection Factories and Destinations and bind it into the local
server’s (or cluster’s) JNDI tree, eliminating the need to put this connectivity/location
information in the MDB itself.
– Are synchronous
– Are maintained in memory
• Processing time includes passivation and activation.
Stateful session beans are very similar to their stateless session bean counterparts. In fact,
stateful session beans and stateless session beans are implemented in exactly the same
manner. However, stateful session beans are designed to maintain state across multiple client
invocations on behalf of the client. The stateful session bean does this by storing stateful
properties in the attributes of the component itself. An EJB container is then responsible for
ensuring that subsequent client invocations for the same stateful bean are routed back to the
object that hosts the stateful attributes.
Stateful session beans and stateless session beans also have many differences. First,
because stateless session beans do not maintain any state, they are more scalable than their
stateful counterparts. A container does not have to worry about handling excessive memory
consumption or tracking which clients own what beans. Also, because stateful session beans
maintain state, they can consume more memory.
In stateful sessions, the container puts the idle EJB instances to secondary (disk) storage and
releases memory to be used by active EJB instances. This process is called passivation.
When a client calls the passivated bean instance again, the container brings into memory the
previously passivated bean from secondary storage and puts it in memory. This is called
activation. Obviously, frequent activation and passivation can be a performance problem.
Specified by the
<max-beans-in-cache> tag
Cache
WLS lets you control how many stateful session EJB instances for one EJB type can be in
memory at a time. At this time, the thresholds that you can set are per EJB type. You cannot
set any thresholds that apply for a group of EJB types together. Also, you can control only the
number of EJBs that are allowed in cache—there are no mechanisms to say, “Consider the
cache to be full if these stateful session EJB instances consume 2 MB of memory.”
So, given this level of cache management, you must answer these questions:
• How big should you set your cache?
• What happens to your EJBs when the cache fills up?
The graphic shows that the application server will host stateful session beans up to the
number specified in the max-beans-in-cache setting.
Passivation
EJB activated
EJB passivated
Cache
Activation
Client
request
The WebLogic Server uses a cache of bean instances to improve the performance of stateful
session EJBs. The cache stores active EJB instances in memory so that they are immediately
available for client requests. Active EJBs consist of instances that are currently in use by a
client, as well as instances that were recently in use.
This graphic shows the WebLogic Server cache and the processes by which stateful EJBs
enter and leave the cache. No stateful session EJB instances exist in the WebLogic Server at
startup time. Before a client begins accessing a stateful session bean, it creates a new bean
instance to use during its session with the bean. When the session is over, the instance is
destroyed. While the session is in progress, the instance is cached in memory.
Activation is the transfer of an EJB instance from secondary storage to memory. Passivation
is the transfer of an EJB instance from memory to secondary storage. Tuning max-beans-
in-cache too high consumes memory unnecessarily. The EJB container performs
passivation when the cache becomes full. W hen the EJB session object is needed again, the
bean is activated by the container.
• Passivation is the
the cache and act of
writing removing
it to a bean
a temporary instance from
store.
• A passivated bean is activated when the requesting client
comes back.
• Activation is the act of retrieving the bean instance from
the temporary store to the cache.
When your stateful session EJB cache begins to fill up, the WLS must make more cache
available to those EJBs that need it. The W LS has two options for freeing up the cache for
use by other EJBs: destroying EJBs that are idle and do not need the memory or passivating
eligible EJBs to the hard drive. Either of these actions has the effect of reducing the number
of EJBs currently consuming cache by one and makes that slot available for another EJB
(either one that is currently passivated or a new one that must be created).
Determining the appropriate size of your stateful session bean cache requires a little bit of
work and analysis. The size of your cache should be dependent upon the amount of memory
available to be consumed for this type of EJB, as opposed to other EJBs. When all the EJBs
are active simultaneously in the system, their total memory consumption does not exceed the
amount available in the Java heap space.
You must calculate the approximate size of each EJB type, the number of EJB types
deployed in the system, and the total amount of heap space. Calculate a fixed cost of 2 to 3
MB of RAM for administration and overhead. The ideal cache size is one that prevents your
entire system from exceeding the total VM space available.
Consider clustering as well, because bean replication uses space in the cache of all servers
in a cluster environment.
A larger cache can improve performance because it reduces the number of passivation
operations; however, it would use up more memory (heap space). You can control
serialization of data variables using the transient keyword to avoid persistence of
unnecessary data during EJB passivation.
WLS performs cache sweeps regularly to optimize performance. Ensuring that the amount of
cache taken up by EJBs is at an appropriate level is important for the efficient operation of the
server. If an EJB exceeds its<idle-timeout-seconds>value that is specified in the
META-INF\weblogic-ejb-jar.xmlfile, it can be destroyed by the WLS. An EJB is eligible
for passivation if it has not exceeded its <idle-timeout-seconds>value, it is not
participating in a transaction, and it is not currently executing a method. Thus, only certain
types of EJBs are eligible for passivation at a time.
Question: An EJB is not currently executing a method, but is participating in a transaction.
Why cannot this EJB be passivated?
Answer: In order for a transaction to maintain integrity, a resource that is participating in the
transaction must remain active and not be destroyed until the transaction has committed or
rolled back. Passivating an EJB could destroy a resource (for example, a database
connection); the active transaction would be compromised by passivation.
When you configure eager passivation for a stateful session bean by setting the cache type to
LRU, the container:
• Passivates instances to disk:
-As soon as an instance has been inactive for idle-timeout-seconds,
regardless of the value of max-beans-in-cache
- When max-beans-in-cache is reached, even though idle-timeout-
seconds has not expired
• Removes a passivated instance from disk after it has been inactive for idle-timeout-
seconds after passivation. This is referred to as a lazy remove.
There are no stateful session EJB instances in the WLS at startup. As clients look up and
obtain references to individual beans, the WLS initializes new instances of the EJB class and
stores them in the cache. Ifmax-beans-in-cache is reached and EJBs in the cache are
not being used, the WLS passivates some of those beans even if they have not reached their
idle-timeout-secondslimit.
When an EJB becomes eligible for passivation, it does not mean that the WLS passivates the
bean immediately. Passivation occurs only when the EJB is eligible for passivation and there
is pressure on server resources, or when the WLS performs regular cache maintenance. You
can specify the explicit passivation of stateful EJBs that have reached idle-timeout-
seconds by setting the cache-type element in the weblogic-ejb-jar.xml file. Specify
LRU when you require more aggressive passivation of EJBs. Specify NRU when you have
memory pressures in the cache and want to keep ni memory the beans your client uses the
most.
For cached EJB instances: When resources become scarce and the cache needs memory,
the WLS examines EJB classes that are approaching their max-beans-in-cache limit. Of
those beans, the WLS removes EJB instances that have not been used for idle-timeout-
seconds from the cache (rather than passivating them to disk).
• ClassLoading Delegation Model states that parent class loaders are to be searched
before the current class loader for a class.
• If the class being loaded is in an archive in the current application, it still has to search
all the way up to the system class loader and finally work it’s way down to the
application’s class loader. As you can imagine, with the hundreds of archives that now
make up W ebLogic Server, this can be an expensive operation
• The Filtering ClassLoader sits between the System ClassLoader and the Application
ClassLoader and intercepts requests for configured classes. If the classes are not found
in the application, it will not search the parent class loaders (so a
ClassNotFoundExceptionor NoClassDefFoundExceptionwill result).
• The same concept applies for resources that we know exist only in the application.
Prefer-application-packages
• Improve class loading time when you know certain packages are contained in your
application
• Use when you have your own version of some package that also exists in parent class
loader
Prefer-application-resources
• Improve resource lookups when you know certain resources are in your application.
Use a gradual ramp-up loading so that you can start seeing issues at the progressive
increase of the load. Do not swamp the WebLogic server with a huge traffic in one blow; it will
simplify your analysis.
session EJBs
These are the slides that were removed from the srcinal set to convert this course into
a workshop format. Some slides were removed because even if they are still supported
features of WebLogic, they may not have the importance that they used to have. Other
slides were removed because their content is covered directly in the activity guide of
this workshop. Students can use these slides as reference while performing the
practices.
Lesson 2: Performance Tuning Overview
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
Answer: a
Answer: e
Answer: a, c, d, e, f
Answer: a, b, c, e
The Grinder worker and agent processes are controlled by setting properties in the
grinder.properties file. All properties have default values. If you start The Grinder agent
process without a grinder.properties file, the agent communicates with the console by
using default addresses, uses one worker process and one thread, and makes one run
through the test script found in the grinder.py file. The available properties include:
• grinder.processes: The number of worker processes that the agent should start
• grinder.threads: The number of worker threads that each worker process spawns
• grinder.runs: The number of runs of the test script that each thread performs. A
value of 0 means “run forever,” and should be used when you are using the console to
control your test runs.
• grinder.processIncrement: If set, the agent will ramp up the number of worker
processes, starting the number specified every
grinder.processesIncrementInterval milliseconds. The upper limit is set by
grinder.processes.
– grinder.properties
• Edit grinder.properties to reflect the load and other
configuration parameters.
• Run The Grinder Console (optional).
• Run Agents and start threads.
• Verify results either on the console or in the log file.
The test directory contains a grinder.properties file that maintains information about the
tests to perform. This directory can be located anywhere on your hard drive; it does not have
to be under The Grinder’s directory. The grinder.properties file contains name/value
pairs for various properties.
Refer to The Grinder documentation for a comprehensive list of parameters and default
values.
TCPProxy
Browser Server
Output
The TCPProxy is a proxy process that you can place in a TCP stream, such as the HTTP
connection between your browser and a server. It filters the request and response streams,
sending the results to the terminal window (stdout). You can control its behavior by
specifying different filters. The TCPProxy’s main purpose is to automatically generate HTTP
test scripts that can be replayed with The Grinder’s HTTP plug-in. Because the TCPProxy lets
you see what is going on at a network level it is also very useful as a debugging tool in its own
right.
The TCPProxy of The Grinder is used by your browser just as any other HTTP proxy server. If
you open http://grinder.sourceforge.net with your browser, it displays the The
Grinder home page, and the TCPProxy outputs all the HTTP interactions between the
browser and the SourceForge site. It is important to remember to remove any “Bypass proxy
server” or “No proxy for” settings that you might have, so that all the traffic flows through the
TCPProxy and can be captured.
Having finished your run-through, click Stop on the TCPProxy console and the generated
script will be written to grinder.py. The grinder.py file contains headers, requests, and a
logical grouping of requests into pages, for the recorded tests. The recorded script can also
be edited manually to suit your needs.
TCPProxy
Browser Server
Output
To start the TCPProxy, set the CLASSPATH togrinder.jar, and then invoke java
net.grinder.TCPProxy.
With no additional options, the TCPProxy starts and displays the initialization as an HTTP or
HTTPS proxy with the following parameters:
• Request filters: EchoFilter
• Response filters: EchoFilter
• Local address: localhost:8001
• Engine initialized, listening on port 8001
The example indicates that the TCPProxy is listening as an HTTP proxy on port 8001.
In the browser options dialog box, set the proxy host to be the host on which the TCPProxy is
running and the proxy port to be 8001. After the test scripts are recorded, three new script
files are created: grinder.properties, httpscript.py, and httpscript_tests.py.
grinder.useConsole=false
grinder.processes=1
grinder.threads=500
grinder.runs=2
grinder.logDirectory=JSP_Test_Results
grinder.numberOfOldLogs=0
grinder.script=exercise/grinderscripts/httpscript.py
The Grinder is controlled by setting properties in the grinder.properties file. The sample
file contains the following parameters:
• It does not use the console, so the agent files run to completion on their own.
• There is only one grinder agent process with 500 threads, with each thread executing
the step twice.
• The results are stored in the JSP_Test_Results folder.
• Runs from different versions are overwritten.
This file defines the actual tests that would be invoked by the
threads. This is an example of anhttpscript.py file.
class TestRunner:
def __call__(self):
tests[0].GET('http://localhost:7011/ShoppingCartApp/')
tests[1].GET('http://localhost:7011/ShoppingCartApp/browse.jsp')
grinder.sleep(2078)
tests[2].POST('http://localhost:7011/ShoppingCartApp/categories',
( NVPair('boxWriting', 'Writing'),
NVPair('btnSubmit', 'Retrieve Items'), ))
NVPair('Accept-Language', 'en-us'),
NVPair('User-Agent', 'Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; SV1; .NET CLR 1.1.4322)'), )
request0 = HTTPRequest(headers = headers0)
tests[0] = Test(0, 'GET ').wrap(request0)
• You can find the results of a load test in the log directory
specified.
– data_host-n.log (individual test invocation data)
– error_host-n.log (errors during the tests)
– out_host-n.log (final statistics summary)
(where host is the machine host name and n is the worker process
number)
• You can view these results either directly in the log file or
on the console.
You can configure The Grinder to retain the log from different runs by setting the
grinder.numberOfOldLogs parameter in the grinder.properties file. When The
Grinder stores the log files, it appends n (the number of running of the test) to the name of the
log.
Start The Grinder and the console from the directory where the grinder.properties file is
located by using the following command:
$ java net.grinder.Console
In the console, select Action > Start processes. If the grinder.receiveConsoleSignals
property is set to true, The Grinder waits until the console starts and you start the processes
from the console.
The console displays the test graphically. It reports the average transactions per second
(TPS), peak TPS, total number of transactions, number of errors, and number of aborts.
Sometimes it takes the console a few moments to display the results.
During a test, you can observe statistics in the console for each test case and the overall
statistics of the tests. The Grinder defines a transaction as an iteration from a client to the
server. It tracks statistics for all requests defined in the grinder.properties file and for
each test. The Grinder tracks the overall TPS, which includes all test cases.
The
for agraph shows the statistics
web application. for all
It tracks the tests, time
average including the tests that
per transaction, access
TPS, the Welcome
average page
TPS, peak
TPS, total number of transactions, the number of errors, and the number of aborts.
Test 1 (POST testdatasource.jsp) shows the statistics for Test 1, which tests a JSP
within a web application.
Answer: a, c
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
• iptraf
– Monitors TCP/IP traffic in a real time manner and generates
real time reports. It shows TCP/IP traffic statistics by each
session, by interface, and by protocol.
• acctcom
– Displays selected process accounting record summaries.
This command reports only on processes that have finished.
• topas
– Reports selected statistics about the activity on the local
system
• gprof
– Reports the flow of control among the subroutines of a
program and the amount of CPU time consumed by each
subroutine.
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
• By setting the throughput goal, you can specify how much total
time the garbage collector can spend for GC.
• Specified with the command-line flag: -XX:GCTimeRatio=nnn
startManagedWebLogic.sh
The throughput collector is a generational collector, so there are separate collections for the
young generation and the old generation. Averages and variances are kept separately for
each generation. The maximum pause time goal is applied to the average plus the variance of
the collections of each generation separately. Each generation may separately fail to meet the
pause time goal.
The throughput goal is measured in terms of the time spent collecting garbage and the time
spent outside of garbage collection (referred to as application time). The goal is specified by
the command-line flag:
-XX:GCTimeRatio=<nnn>
The ratio of garbage collection time to application time is 1 : nnn.
For example, if you set -XX:GCTimeRatio=24, this will set a goal of 1/(1+24), 1/25th, or 4%,
which means 4% of the total time is the goal for garbage collection, and the rest will be
application time.
The time spent in garbage collection is the total time for both young generation and old
generation collections combined. If the throughput goal is not being met, the sizes of the
generations are increased in an effort to increase the time the application can run between
collections.
startManagedWebLogic.sh
The throughput collector is a generational collector, so there are separate collections for the
young generation and the old generation. Averages and variances are kept separately for
each generation. The maximum pause time goal is applied to the average plus the variance of
the collections of each generation separately. Each generation may separately fail to meet the
pause time goal.
Yes Reduce
GC Pause
Generation Size
> Goal? by 5%
No
Increase
Yes
Throughput Generation
< Goal? Sizes by a Total
of 20%
No
startManagedWebLogic.sh
• In J2SE 5.0 and later, you can set this flag dynamically by
changing the verbose attribute of
java.lang.management.MemoryMXBean.
• You can print information for every collection by using the
-verbose:gc flag.
Redirect both the standard error and standard output to a log file to analyze -verbose:gc
output:
For example, on Windows and Solaris:
> java -Xms200m -Xmx512m -XX:+PrintGC ... weblogic.Server >>
logfile.txt 2>&1
The -XX:+PrintGCDetails flag prints additional information about the collections.
• To achieve
footprint, the maximum
smaller heaps arepause
used.time goal and a minimum
• The implementation of -XX:+UseAdaptiveSizePolicy
is used by default with the Parallel Collector.
• Multiple goals, such as –XX:GCTimeRatio and
-XX:MaxGCPauseMillis, can be defined in the
command-line while starting the JVM.
The heap size parameters selected by ergonomics and the features of the adaptive size
policy are meant to provide good performance for server applications.
You can define multiple goals for JVM. When multiple goals are defined, the priority of the
goals is in the following order:
• Maximum pause time goal
• Throughput goal
• Minimum footprint goal
-XX:-BytecodeVerificationLocal -XX:-BytecodeVerificationRemote
-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=536870912
-XX:MaxPermSize=268435456 -XX:+PrintCommandLineFlags
-XX:+UseCompressedOops -XX:+UseParallelGC
Server Console Window
In most cases, if you have GUI access to the machines running JVMs, you would more likely
use Java VisualVM. Java VisualVM usesjinfo for getting the details of JVM and presents
them within its GUI interface. However, when you are limited to access through command-line
options only, then jinfo is very useful.
The application snapshot enables you to capture and archive the status of JVM at a point in
time. The target JVM does not need to be running to view the snapshot. Snapshots can also
be sent and viewed by other people.
• An application snapshot also captures general information about the JVM such as heap
dumps, thread dumps, and profiler snapshots at the moment the snapshot is taken.
• You take an application snapshot by right-clicking an application node in the
Applications window and choosing Application Snapshot from the pop-up menu.
• Application snapshots are persisted between Java VisualVM sessions.
• When you take an application snapshot:
- An application snapshot node appears under the Snapshots node in the
Applications window
- Application data is saved in a subfolder in the repository or snapshots folder in the
Java VisualVM user directory
-
Application snapshots are listed under the Snapshots node in the Applications
window. Expand the application snapshot node to view the contents of the
snapshot.
• After you take an application snapshot, you can view and modify the contents. You can
then save the application snapshot as a single application snapshot archive (.apps) to
your local system.
Oracle WebLogic Server 12c: Performance Tuning Workshop A - 35
Lesson 5: Monitor and Tune Server Performance
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
You can set up servers in a domain to run either in development mode or in production mode.
In general, production mode requires you to configure additional security features. You can
set up a domain in development mode and then easily move to production mode. After you
have changed to production mode, you cannot change back to development mode without
restarting the server.
To configure all servers in a domain to run in production mode:
1. If you have not already done so, in the Change Center of the Administration Console,
click Lock & Edit.
2. In the left pane of the Console, under Domain Structure, select the domain name.
3. Select Configuration > General and select the Production Mode check box.
4. Click Save, and then, to activate these changes, in the Change Center, click Activate
Changes.
5. Shut down any servers that are currently running.
6. Invoke the domain’s startWebLogic script. The Administration Server starts in the
new mode.
7. If the domain contains Managed Servers, start the Managed Servers. The Managed
Servers also start up in the defined mode.
Answer: a
An example of an applications configuration file showing work manager for stuck threads:
• Configured in weblogic-ejb-jar.xml file:
...
<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
...
– Pending Requests
– Max Wait Time
– Current Wait Time
Setting the min thread constraint will essentially cause work for that work manager to
immediately be scheduled as long as there aren’t the specified number of concurrent
requests already processing. That is, if the min thread constraint value is set to 5, WLS
will always schedule work for that work manager immediately until there is 5 concurrent
requests processing—bypassing all other requests sitting in the execute queue!
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and
the server side, uses to read data from and write data to sockets. 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 the server side can boost performance.
A chunk is a unit of memory that the WebLogic Server network layer 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 4 KB.
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 whether the value needs to
be increased, monitor the CPU profile or use a memory or 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 load over
multiple partitions and reduces potential for contention over one partition.
Oracle WebLogic Server 12c: Performance Tuning Workshop A - 47
Tuning the Chunk Pool Size
-Dweblogic.utils.io.chunkpoolsize=n .
• The default chunk pool size is 512.
• Tuning the pool size accommodates workloads with
particular payloads and concurrent client activity.
• You should set a large pool size to accommodate
workloads with many concurrent clients.
Check the creation of chunk class and try to minimize this by setting chunk pool size.
Answer: a, b, d, e, f
If the Accept Backlog value is set too low, most connections will
be dropped or refused at the client.
a. True
b. False
Answer: a
the server.
c. The WLS server health-checking system will always block
incoming requests to ensure that the server never has to
deallocate an EJB due to lack of memory.
Answer: b
a. This statement
a dedicated SSLis accelerator.
false. WLS can process SSL faster than
b. The statement is false. There is no such thing as a
dedicated SSL accelerator.
c. This statement is true.
Answer: c
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
b. Remote calls
the SOAP are expensive because they always involve
stack.
c. Remote calls can be expensive because they involve
serialization and deserialization to send the data.
d. Remote calls are not expensive.
e. None of the above
Answer: a, c
Answer: a, c
In general, hardware load balancers perform better than software load balancers; however,
hardware load balancers can be very expensive when compared to their software
counterparts. Performance can far outweigh the cost depending on the criticality of the
application.
A few examples of load balancers are:
• Hardware load balancer: Cisco, Foundry Networks, and Big IP
• Software load balancer: Oracle HTTP Server, Apache, Netscape, IIS, and WebLogic
Server (via proxy plug-ins)
b. Pages-served performance
c. Compilation rate of JSPs
d. Flow of connections to the servers
e. Management and configuration tools
f. Security
g. Load-balancing algorithms
Answer: a, b, d, e, f, g
Coherence:
• Provides a distributed, in-memory caching solution for
Java
• Is based on a grid of cache servers or nodes
One of the primary uses of Oracle Coherence is to cluster an application’s objects and data.
In the simplest sense, this means that all the objects and data that an application delegates to
Coherence are automatically available to and accessible by all servers in the application
cluster. None of the objects or data will be lost in the event of server failure. By clustering the
application’s objects and data, Coherence solves many of the difficult problems related to
achieving availability, reliability, scalability, performance, serviceability, and manageability of
clustered applications.
Oracle Coherence is a JCache-compliant, in-memory caching and data management solution
for clustered Java EE applications and application servers. Coherence makes sharing and
managing data in a cluster as simple as on a single server. It accomplishes this by
coordinating updates to the cached data by using clusterwide concurrency control, replicating
and distributing data modifications across the cluster, and delivering notifications of data
modifications to any servers that request them. Developers can easily take advantage of
Coherence features by using the standard Java Collections API to access and modify data,
and by using the standard JavaBean event model to receive data change notifications.
Coherence provides a clusterwide view of management information through the standard JMX
API, so that the entire cluster can be managed from a single server. The information provided
includes cache sizes along with hit and miss rates.
<session-descriptor>
<persistent-store-type>
replicated
</persistent-store-type>
</session-descriptor>
In-memory replication:
<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
<session-descriptor>
File persistence:
<session-descriptor>
<persistent-store-type>file</persistent-store-type>
<persistent-store-dir>Directory Path</persistent-store-dir>
<session-descriptor>
JDBC persistence:
<session-descriptor>
<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>Data Source Name</persistent-store- pool>
<session-descriptor>
Answer: e
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
– Three-tier: Clients
and the middle tiermake a request
connects to the to the middle
database tier (Wof
on behalf LS)the
client.
JDBC
WLS Database
driver
Java
application
JDBC
Database
driver
JDBC drivers are simply collections of classes that implement known methods defined by the
JDBC driver specification. These drivers fall into two broad classes: two-tier and three-tier.
Two-tier drivers are used by a client regardless of who that client is, to access a database
directly. In a three-tier driver, the WebLogic Server (WLS) acts as a middleman, optimizing
connections to the underlying database, typically via a connection pool. A connection pool is a
collection of connections to a database. Connections in a connection pool are created at boot
time by the W LS. The connections of a connection pool are configured to use a particular
JDBC driver and connect to a specific database.
The graphic shows that applications can directly connect to a database by using JDBC, and
that WLS can also connect to databases by using JDBC.
Java application
JDBC API
JDBC-ODBC JDBC-Native JDBC-Net All Java
Bridge Bridge Bridge JDBC Driver
(Type 1) (Type 2) (Type 3) (Type 4)
Network
Server
(WLS)
RDBMS
Applications that use JDBC can use one of four different JDBC driver types. The first type of
driver is the JDBC-ODBC bridge. The Java program accesses a database through a client-
configured Open Database Connectivity (ODBC) connection. A client application can also use
a JDBC driver that accesses the client-side-installed native API driver for a particular
database. A Type 2 driver provides a bridge from the Java JDBC API into the native driver
installed on the client. The native driver has the protocols and knowledge to communicate
directly with the database. The Type 3 driver, or a multitier implementation, uses a network
server to relay or proxy the JDBC requests onto the database. The Type 4 driver is an all-
Java implementation of the JDBC native database driver. The database and the JDBC
application perform direct Java-to-Java calls using this driver type. As a distinction, the JDBC
drivers that allow a client machine to communicate directly with the database are called two-
tier implementations, whereas the proxy of the Type 3 driver is called a multitier
implementation.
The graphic shows four types of JDBC drivers. It shows that Type 3 driver uses a Network
Server.
Data sources:
• Are administered factory objects that provide JDBC
connections
• Are bound into the Java Naming and Directory Interface
A data source is a J2EE concept that allows for abstracting a JDBC connection. With a data
source, a developer or administrator can specify an object that represents a database. In the
case of the WebLogic Server, a data source is a wrapper around a connection pool. A user
can then access the data source and use it to create a connection to the underlying database
via the connection pool associated with the data source. The data source concept allows the
developer to be completely unaware of the connection pool or database that is used to
provide the connection. Although the slide depicts only “normal” data sources, the WebLogic
Server supports both transactional and non-transactional data sources. Transactional data
sources have the added advantage that any actions they participate in can be part of a
transaction.
The graphic shows that the Java application uses JNDI to obtain a reference to a data source.
It does this using a lookup(). The Java application then gets a connection from the data
source by using the getConnection() call. The Java application is then able to make calls
on to the database by using that connection.
Answer: c
c. TRANSACTION_REPEATABLE_READ
d. TRANSACTION_SERIALIZABLE
e. TRANSACTION_READ_SERIALIZABLE
f. T RANSACTION_REPEATABLE_UNCOMMITTED
Answer: a, b, c, d
The WebLogic Server includes support for the Logging Last Resource (LLR) transaction
optimization through JDBC data sources. Logging Last Resource is a performance
enhancement option that enables one non-XA resource to participate in a global transaction
with the same atomicity, consistency, isolation, durability (ACID) guarantee as XA. The
Logging Last Resource uses a local transaction for its transaction work. The WebLogic Server
transaction manager prepares all other resources in the transaction and then determines the
commit decision for the global transaction based on the outcome of the Logging Last
Resource’s local transaction.
In many cases, a global transaction becomes a two-phase commit (2PC) transaction because
it involves a database operation (using JDBC) and another nondatabase operation, such as a
message-queuing operation (using JMS). In cases such as this where there is one database
participant in a 2PC transaction, the Logging Last Resource Optimization transaction option
can significantly improve transaction performance by eliminating some of the XA overhead for
database processing and by avoiding the use of JDBC XA drivers, which typically are less
5 Commit XA resources
Prepare XA
resources
2
• Start Tx XA Data
• Use data sources Source
1 • Post message
4 Commit non-XA work
• Commit Tx
WLS
Non-XA Data
Application Transaction
Source
(Tx) Manager
3 4
JMS X A
Record Tx for Connection
high availability
2 5
Each WebLogic Server instance maintains a database Logging Last Resource table on the
database to which a JDBC Logging Last Resource data source pools database connections.
These tables are used for storing transaction log records and are automatically created. If
multiple Logging Last Resource data sources are deployed on the same WebLogic Server
instance and connect to the same database instance and database schema, they will also
share the same Logging Last Resource table. The Logging Last Resource table names are
automatically generated unless administrators choose to configure them. The default table
name is WL_LLR_SERVERNAME.
In a global two-phase commit (2PC) transaction with a Logging Last Resource participant, the
WebLogic Server transaction manager follows these basic steps:
1. Receives a commit request from the application
2. Calls a prepare on all other (XA-compliant) transaction participants
3. Inserts a commit record to a table on the Logging Last Resource participant (rather than
to the file-based transaction log)
4. Commits the Logging Last Resource participant’s local transaction (which includes both
the transaction commit record insert and the application’s SQL work)
5. Calls a commit on all other transaction participants
6. After the transaction completes successfully, lazily deletes the datab ase transaction log
entry as part of a future transaction
Oracle WebLogic Server 12c: Performance Tuning Workshop A - 70
Configuring the Logging Last Resource
Options available
only to non-XA
data sources
The Logging Last Resource optimization provides a significant increase in performance for
insert, update, and delete operations. However, for read operations with Logging Last
Resource, performance is somewhat slower than read operations with XA. For best
performance, you may want to configure a non-Logging Last Resource JDBC data source for
read-only operations.
The server will not boot if a Logging Last Resource table is unreachable during boot. Logging
Last Resource transaction records must be available to correctly resolve in-doubt transactions
during recovery, which runs automatically at server startup. If a transaction’s coordinating
server crashes before a Logging Last Resource stores its transaction log record or before a
Logging Last Resource commits, the transaction rolls back. If the server crashes after the
Logging Last Resource is committed, the transaction will eventually fully commit. During
server boot, the transaction coordinator will use the Logging Last Resource to read the
transaction log record from the database and then use the recovered information to commit
any unfinished work on any participating non-Logging Last Resource XA resources.
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
Stuck thread
after 10 minutes
Select a server and locate its Configuration > Overload tab. The following fields relate to stuck
thread handling:
• Shared Capacity For Work Managers: The total number of requests that can be
present in the server. This includes requests that are in the queue and awaiting
execution as well as those under execution. The server performs a differentiated denial
of service on reaching the shared capacity. A request with higher priority will be
accepted in place of a lower priority request already in the queue. The lower priority
request is kept waiting in the queue until all high priority requests are executed.
Additional lower priority requests are rejected right away.
• Failure Action: Enable automatic shutdown or suspension of the server on a failed
state. The server self-health monitoring detects fatal failures and marks the server as
failed.
• Max Stuck Thread Time: The number of seconds that a thread must be continually
working before this server considers the thread stuck
• Stuck Thread Count: The number of stuck threads after which the server is transitioned
into FAILED state. Mark the server instance as failed and shut it down if there are stuck
threads in the server. In a cluster, clustered clients that are connected or attempting to
connect will fail over to another cluster member.
<application-admin-mode-trigger>
<max-stuck-thread-time>300</max-stuck-thread-time>
<stuck-thread-count>5</stuck-thread-count>
</application-admin-mode-trigger>
weblogic-application.xml
Answer: d
c. config/workmanager-<num>.xml
d. weblogic-application.xml
Answer: a
Using the administration console, you can create global work managers that are used to
prioritize thread execution. To create a global work manager:
1. In the left pane of the con sole, expand Environment and select Work Managers. Click
New.
2. Select Work Manager, and click Next.
3. In the Name field, enter a name for the new work manager. Click Next.
4. In the Available Targets list, select the server instances or clusters on which you will
deploy applications that reference the work manager. Then, click Finish.
ClassType Description
Fair Share A numeric weight that represents the average percentage of
thread execution time while under load (default=50)
Context
Fair Share
Request Class
Request Class
Work 80%
Group A
Manager
Group B Fair Share
Request Class
20%
There are multiple types of request classes, each of which expresses a scheduling guideline
in different terms. A Work Manager may specify only one request class.
A fair share request class specifies the average thread-use time required to process requests.
For example, assume that WebLogic is running two modules. The Work Manager for Module
1 specifies a fair share of “80” and the Work Manager for Module 2 specifies a fair share of
“20.” During a period of sufficient demand, with a steady stream of requests for each module
such that the number of requests exceeds the number of threads, the WebLogic Server will
allocate 80% and 20% of the thread-usage time to Module 1 and Module 2, respectively.
A response time request class specifies a response time goal in milliseconds. Response time
goals are not applied to individual requests. Instead, the WebLogic Server computes a
tolerable waiting time for requests with that class by subtracting the observed average thread-
use time from the response time goal, and schedules requests so that the average wait for
requests with the class is proportional to its tolerable waiting time.
A context request class aggregates one or more other request classes, and assigns each to a
unique username or group.
3
1
After you have created a global work manager, you typically create at least one request class
or constraint and assign it to the work manager. Each work manager can contain only one
request class, but you can share request classes among multiple work managers. To create a
global request class:
1. In the left pane of the con sole, expand Environment and select Work Managers. Click
New and then select the type of global request class that you want to create. Click Next.
2. For a fair share request class, enter the numeric weight in the Fair S hare field. For a
response time request class, enter a time in milliseconds in the Response Time Goal
field. When finished, click Next.
3. In the Available Targets list, select the server instances or clusters on which you will
deploy applications that reference this request class. Then, click Finish.
4. Edit your existing work manager. Select your new request class by using the Request
Class field, and click Save.
ConstraintType Description
Minimum Threads The minimum number of threads that the server should
allocate to avoid deadlocks
A maximum threads constraint limits the number of concurrent threads executing requests
from the constrained work set. The default is unlimited. For example, consider a constraint
defined with maximum threads of 10 and shared by three entry points. The scheduling logic
ensures that not more than 10 threads are executing requests from the three entry points
combined. You can define a static value for this constraint or in terms of the availability of a
dependent resource, such as a JDBC data source connection pool.
A minimum threads constraint guarantees the number of threads the server will allocate to
affected requests to avoid deadlocks. The default is zero.
A capacity constraint causes the server to reject requests only when it has reached its
capacity. The default is -1. Note that the capacity includes all requests, queued or executing,
from the constrained work set. Work is rejected either when an individual capacity threshold is
exceeded or if the global capacity is exceeded. This constraint is independent of the global
queue threshold.
4
Edit work manager and
3
assign request class
There has to be one request class or constraint or both defined within a Work Manager. The
Work Manager snippet in the slide uses one request class and one constraint. The Work
Managers cannot have more than one request class; however, it can contain many
constraints.
Snippet from config.xml:
<work-manager>
<name>priority_work_manager</name>
<fair-share-request-class>
<name>very_high_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>min_five_Threads</name>
<count>5</count>
</min-threads-constraint>
</work-manager>
You can create constraints that are independent of Work Managers. Then you can create
Work Managers and assign the constraints to the Work Managers. This way you can share
constraints among Work Managers.
In your deployment descriptors, you reference one of the work managers, request classes, or
constraints by its name.
An enterprise application (EAR) cannot be directly associated with a work manager, although
it can define its own application-scoped work managers. Instead, individual modules within
the enterprise application can reference global or application-scoped work managers.
For web or web-service applications, use the wl-dispatch-policy element to assign the
web application to a configured work manager by identifying the work manager name. This
web application-level parameter can be overridden at the individual servlet or JSP level by
using the per-servlet-dispatch-policy element.
For EJB applications, use the dispatch-policy element to assign individual EJB
components to specific work managers. If nodispatch-policy is specified, or the
specified dispatch-policy refers to a nonexistent work manager, the server’s default work
manager is used instead.
c. Response Time
d. Cluster
Answer: d
b. The Stuckthe
increase Thread
threadWork
pool Manager is configured
to compensate tothreads.
for stuck always
c. The Stuck Thread Work Manager is configured to shut
down the Work Manager by killing all threads in response
to stuck threads parameters.
Answer: a
These are the slides that were removed from the srcinal set to convert this course into
a workshop format.
The WebLogic Server offers session persistence mechanisms that cater to the differing
requirements of your application. The session persistence mechanisms are configurable at
the Web application layer. The session management strategy that you choose for your
application depends on real-world factors such as HTTP session size, reliability, and session
failover requirements. In terms of pure performance, the in-memory session persistence is a
better overall choice. However, in-memory-based session persistence requires the use of
WebLogic clustering, so it is not an option in a single-server environment.
As a general rule, you should optimize your application so that the WebLogic Server does as
little work as possible when handling session management and persistence. The use of
sessions involves a scalability trade-off in most contexts. Use sessions only for states that
cannot realistically be kept on the client or if URL rewriting support is required. For example,
keep simple bits of states, such as a user’s name, directly in cookies. Similarly, keep
frequently used values in local variables if appropriate.
In your application, try to segregate changing session data into a single session attribute. 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, causing unnecessary network overhead.
...
<session-descriptor>
<persistent-store-type>file</persistent-store-type>
<cache-size>2056</cache-size>
...
</session-descriptor>
...
You can configure the number of sessions that are held in memory for an application by using
several parameters in the <session-descriptor> element of the weblogic.xml
deployment descriptor file.
The <cache-size> parameter limits the number of cached sessions that can be active in
memory at any one time. It is applicable only for file and JDBC persistence. If you expect high
volumes of simultaneous active sessions, you do not want these sessions to soak up the
RAM of your server because this may cause performance problems swapping to and from
virtual memory. When the cache is full, the least recently used sessions are stored in the
persistent store and recalled automatically when required. By default, the number of cached
sessions is 1,028. To turn off caching, set this to 0.
The <invalidation-interval-secs> parameter sets the time, in seconds, that the
WebLogic Server waits between doing house-cleaning checks for timed-out and invalid
sessions, and deleting the old sessions to free up memory. Use this element to tune the
WebLogic Server for best performance on high-traffic sites. The default value is 60 seconds.
implements
invocations specific code to preserve its state between
c) The moment a Stateless Session Bean implements code
for state preservation across invocations, it automatically
becomes a Stateful Session Bean
Answer: b
A Stateless Session Bean defined through the @Stateless annotation remains a
Stateless Session Bean for the duration of the application, it is placed in Stateless Bean
pool and is treated by WebLogic as a Stateless Bean. It can implement, however, code
which saves its state to the database and retrieves it when invoked by the same or
another session. In this case state is maintained, but the bean is still a Stateless Bean.
Answer: c
a Web Service
c) A Stateful Session Bean can implement a Web Service,
but a Stateless Session Bean cannot.
Answer: a
Singleton session beans maintain their state between client invocations but are not
required to maintain their state across server crashes or shutdowns.
Applications that use a singleton session bean may specify that the singleton should be
instantiated upon application startup, which allows the singleton to perform initialization
tasks for the application. The singleton may perform cleanup tasks on application
shutdown as well, because the singleton will operate throughout the lifecycle of the
application.
threads concurrently.
• The application needs an enterprise bean to perform tasks
upon application startup and shutdown.
• The bean implements a web service.