ORacle Tune Improvement

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Activity Guide
D61529GC20
Edition 2.0
January 2011
D69372
Oracle University and Sentra inversiones y servicios LTDA use only
Oracle WebLogic Server 11g:

Monitor and Tune
Performance
Disclaimer
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 in any way.
Except where your use constitutes "fair use" under copyright law, you 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 the express authorization
of Oracle.
The information contained in this document is subject to change without notice. If you 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
warranted to be error-free.
Restricted Rights Notice
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 applicable:
U.S. GOVERNMENT RIGHTS
The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted
by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract.
Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
Author
Shankar Raman
Technical Contributors and Reviewers
Bala Kothandaraman, Matthew Slingsby, Serge Moiseev, Nagavalli Pataballa, Werner Bauer,
TJ Palazzolo, Nicole Haba, Madhavi Siddireddy, Pete Daly, Sebastian Colas
This book was published using:
Oracle Tutor
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright 2010, 2011 Oracle and/or its affiliates. All rights reserved.
Practices for Lesson 1 .....................................................................................................................................1-1

Overview of Practices for Lesson 1 ................................................................................................................1-2
Practice 1-1: Getting Familiar with the Lab Environment ...............................................................................1-3
Practice 2-1: Setting Up and Using The Grinder for Load Testing .................................................................2-3
Practice 3-1: Monitoring and Tuning Oracle JRockit JVM ..............................................................................3-3
Practice 3-2: Analyzing Recorded JRockit Flight Recorder Sessions ............................................................3-7
Practice 4-1: Monitoring and Tuning HotSpot JVM ........................................................................................4-3
Practice 5-1: Using Work Managers...............................................................................................................5-3
Practices for Lesson 7....................................................................................................................................7-2
Overview of Practice 7-1: Tuning JSP............................................................................................................7-3
Practice 8-1: Monitoring and Tuning JDBC ....................................................................................................8-3
Practice 9-1: Tuning EJB ...............................................................................................................................9-3
Practices for Lesson 10 ...................................................................................................................................10-1
Overview of Practices for Lesson 10 ..............................................................................................................10-2
Practice 10-1: Tuning JMS .............................................................................................................................10-3
Practice 11-1: Tuning Session Persistence ....................................................................................................11-3
Copyright 2010, Oracle and/or its affiliates. All rights reserved.
Oracle WebLogic Server 11g: Monitor and Tune Performance Table of Contents
i
Table of Contents
Chapter 1
Practices for Lesson 1
Chapter 1 - Page 1
Practices Overview
Lab Familiarity
The lab uses a Linux machine. The instructor will give you the operating system usernames and
password to be used by your team.
The key tasks you perform in this practice are:
Logging in to your machine

Locating your lab file location
Starting and stopping Oracle 11g Database and its listener

These exercises use the following variable names to refer to commonly used locations on your
file system:
Variable
Path
Database
(ORACLE_HOME)
/u01/app/oracle/Database/11.2.0/orcl
<Middleware_HOME>
<MW_HOME>
/u01/app/oracle/Middleware/11.1.1
<WL_HOME>
<MW_HOME>/wlserver_10.3
<STUDENT>
/home/oracle/wls11g_tune
<CURRENT_LAB>
<STUDENT>/labs/labXX_YY,
where XX_YY is the current practice number (for example,

lab01_01)
<LAB_WORK>
/u01/app/work
<DOMAIN_HOME>
<LAB_WORK>/domains/MedRecDomain
/ptcourse
/
<GRINDER_HOME>
/u01/app/opensource/grinder-3.2

Chapter 1 - Page 2
Overview of Practices for Lesson 1
1.
2.
Make sure that your machine is powered on. Log in as the oracle user with the password
provided by your instructor.
After you have logged in to the desktop, you may want to get familiar with the desktop
interface.
a. You will notice four palettes at the bottom right of your remote machine. Each of them
represents a desktop on the remote machine.
b. For your convenience, you can invoke different applications to full screen on each
desktop appropriately.
1) You can invoke a gnome-terminal on the first desktop by using the Terminal icon
on the desktop.
2) Invoke a Web browser on the second desktop by using the icon on the menu bar.
3)
3.
Invoke a file browser in the third desktop by using Applications > System Tools >
File Browser.
Oracle Database 11g and Oracle WebLogic Server 11g are already installed and
configured in your machine. Using the File Browser, navigate through the installation and
configuration directories.
a. Using the File Browser, navigate the File System tree to the
/u01/app/oracle/Database/11.2.0/orcl folder. This folder is the
ORACLE_HOME folder for the database. The executables and main configurations for
database are in this folder.

Chapter 1 - Page 3
Practice 1-1: Getting Familiar with the Lab Environment
4.
Now navigate to /u01/app/oracle/Middleware/11.1.1. This folder contains the

installed binaries for the Oracle Fusion Middleware components.
Using the gnome-terminal session, perform the following steps to get familiar with the
scripts that you will use in the practices.
a. The wls11g_tune/bin folder contains the scripts and tools to start and stop the
database and the WebLogic server instances that you will use in the practices for this
course.
b. Navigate to the wls11g_tune/bin subfolder in your $HOME folder (/home/oracle) and
list the files in this folder:
$> cd /home/oracle/wls11g_tune/bin
$> ls
c.
Execute the ps command to check whether the database is running. If it is not running,
use the start_db.sh script to start the database.
$> ps ef | grep pmon
Note: If the preceding command does not return the ora_pmon_orcl row, you must start
the database using the start_db.sh script.
$> start_db.sh

Chapter 1 - Page 4
b.
Chapter 2
Chapter 2 - Page 1
Practices Overview
This practice was developed and tested using a machine with one CPU and 2 GB of RAM. The
results shown and discussed may vary depending on the resources in the environment that you
are using.

Chapter 2 - Page 2
Skills Learned
At the end of this practice, you should be able to:
Start a Grinder agent using The Grinder console
Configure and run a test using The Grinder console

Set up a test script for monitoring an application
Run the test script and evaluate performance metrics

Overview
In this practice, you set up a WebLogic Server domain. You also set up The Grinder and record
load test script. Then you use the load test script to record performance metrics in your
environment.
Instructions
1. Set up the MedRec domain environment. The setup script creates the MedRec domain and
starts the administration and a managed server for MedRecDomain in their individual
gnome-terminals.
a. Invoke a gnome-terminal and set up the environment variables required to run the
practices by using the set_course_env.sh script in the
/home/oracle/wls11g_tune/bin folder:
$> cd /home/oracle/wls11g_tune/bin
$> source ./set_course_env.sh
b.
Navigate to the /home/oracle/wls11g_tune/labs/lab02_01 folder and run the

ant script with the setup_medrec option to start Oracle Database 11g and to set up
MedRecDomain.
$> cd /home/oracle/wls11g_tune/labs/lab02_01
$> ant setup_medrec
You see a window titled MedRecDomain open that has the Admin Server start up.
Similarly, you see another window open with title MedRec Server1. When prompted, enter
the username weblogic. Then enter the password Welcome1.
The process will complete in about five minutes.
c. When you see that the MedRec Server 1 is in the RUNNING state in the window titled
MedRec Server 1, verify that you can use the Medical Records application in your Web
browser by accessing the following URL:
http://localhost:7021/medrec/index.action
d. Log in as the patient fred@golf.com with the password weblogic.

Chapter 2 - Page 3
Practice 2-1: Setting Up and Using The Grinder for Load Testing
Configure the TCP proxy for The Grinder and start it to enable you to record test scripts.
a. Close all the Firefox windows in your system.
b. In a shell window, navigate to the Firefox configuration subfolder in the
/home/oracle/.mozilla/firefox folder (such as
/home/oracle/.mozilla/firefox/gc102iya.default), and copy prefs.js
to prefs.js_BAK.
$> cd /home/oracle/.mozilla/firefox/gc102iya.default
$> cp prefs.js prefs.js_BAK
c.
d.
3.
Invoke Firefox and navigate to the Network tab by using Edit > Preferences >
Advanced > Network.
Click the Settings button and edit the following values. Then click OK and finally click
Close.
Field
Value
HTTP Proxy
localhost
Port
8001
No Proxy For
<empty>
e.
f.
Restart Firefox. You receive an error because the proxy server is not yet running.
Invoke another gnome-terminal window and run the following command:
$> source set_course_env.sh
g.
Start the TCP proxy for The Grinder to begin recording the test script. Navigate to the
/home/oracle/wls11g_tune/labs/lab02_01/grinder folder and execute the
following:
$> source ./setEnv.sh
$> java net.grinder.TCPProxy -console -http >
viewrecords-updateprofile.py
h.
Confirm that the proxy started successfully:

(tcpproxy): Engine initialised, listening on port 8001
i.
The TCPProxy Console window is also displayed:
Access the application and perform test tasks to record the test scripts.
a. Invoke Firefox and access the following URL:
http://localhost:7021/medrec/index.action
b.
c.
d.
e.
Log in as the patient fred@golf.com/weblogic.

Click the Successfully Logged in! Click Here to Continue link.
Tip: If you make a mistake, you will need to first kill and restart the TCP proxy, and
then start over from the initial URL.
Click one of the links in the Visit Records table.
Click your browsers Back button to return to the patients main page. Test the
remaining records.

Chapter 2 - Page 4
2.
4.
Click the Profile and then click the Logout button.

In the TCPProxy Console, click the Stop button.
Inspect the generated test script, viewrecords-updateprofile.py.
Close Firefox.
In the gnome-terminal window navigate to the
/home/oracle/.mozilla/firefox/gc102iya.default folder and copy
prefs.js_BAK to prefs.js.
Start The Grinder Console.
a. In the gnome-terminal window, ensure that you have already set The Grinder
environment variables by using setEnv.sh as specified in step 2 g. Then navigate
to/home/oracle/wls_11g_tune/labs/lab02_01/grinder, and start The
Grinder Console by using the following:
$> cd ~/wls11g_tune/labs/lab02_01/grinder
$> source setEnv.sh
$> java net.grinder.Console &
b.
In The Grinder Console, set the following: (Note that the console may show Collect
samples forever. It will change to Stop after ... when you enter the value 1000.)
Sample Interval
1000 ms
Ignore
0 Samples
Stop after
1000 samples
c.
View the grinder.properties file in the

~/wls11g_tune/labs/lab02_01/grinder/ folder with these values: (If necessary
create the file and insert these lines and save your changes.)
grinder.processes=1
grinder.threads=50
grinder.runs=2
grinder.logDirectory=logs
grinder.numberOfOldLogs=2
grinder.script=viewrecords-updateprofile.py
d.
Launch another gnome-terminal and run the set_course_env.sh shell script.

e.
Navigate to ~/wls11g_tune/labs/lab02_01/grinder and execute the following:

$> java net.grinder.Grinder
f.
Confirm that your agent started successfully and that it discovered your console:
(agent): connected to console at localhost/127.0.0.1:6372

Chapter 2 - Page 5
f.
g.
h.
i.
j.
5.
Run the test case and record the performance metrics.

a. Return to The Grinder Console and access the Results tab.
b. On the main toolbar, select Action > Start processes. Click OK if prompted to run the
agents default property file. (Also, if not already selected, select Action > Start
Collecting on the toolbar.)
c. As the agent runs, the left pane displays the number of collected samples. You can
view the statistics relating to the load test:
d.
e.
f.
g.
On the Results tab of The Grinder Console, locate the Successful Tests column.
When most of the rows are within the range after about 35 minutes, click Stop
Collecting and, if necessary, select Stop processes on the task menu.
Return to the gnome-terminal in which you initiated The Grinder agent, and verify that
the test script completed:
11/5/09 2:36:04 PM (agent): finished
Record the following values found in the Total row of results table of the console:
Number of
Successful Tests
6.
Number of Errors
Mean Response
Time (ms):
Mean TPS
h. Close The Grinder console (using File > Exit on the menu).
Modify the server heap settings and perform the test again so that you can compare the
results.
a. Stop the managed server by using the stop_mr1.sh script. Enter the username and
password when prompted.
$> stop_mr1.sh

Chapter 2 - Page 6
(agent): waiting for console signal
Within the same terminal, ensure that you use Sun as the JAVA_VENDOR, set the
memory options, and start MedRecSvr1 using the following:
$>export JAVA_VENDOR=Sun
$> USER_MEM_ARGS="-Xms512m Xmx512m XX:MaxPermSize=256m"
$> export USER_MEM_ARGS
$> cd /u01/app/work/domains/MedRecDomain/bin/
$> ./startManagedWebLogic.sh MedRecSvr1 t3://localhost:7020
c.
7.
Inspect the servers output to verify that the new heap settings are in tune with the
USER_MEM_ARGS parameter.
Repeat step 4 (Start The Grinder Console) and step 5 (Run the test case and record the
performance metrics). Re-enable data collection in The Grinder Console.
a. Compare the performance (Mean Response Time and Mean TPS).
b.
Stop the MedRecSvr1 and MedRecAdm servers by using the scripts.

$> stop_mr1.sh
$> stop_mradm.sh
are using.

Chapter 2 - Page 7
b.
Chapter 2 - Page 8
Chapter 3
Chapter 3 - Page 1
Practices Overview
are using.

Chapter 3 - Page 2
In this practice, you:
Monitor Oracle JRockit by using the JRockit Management Console
Tune heap size for JRockit JVM and monitor performance
Overview
The performance of the WebLogic Server instances can be tuned by tuning the underlying
JRockit JVM. The tools provided by the JVM will come in handy while monitoring the JVM. The
WebLogic Server runs out of memory for any number of reasons. Memory leaks present in the
application code deployed on the WebLogic Server can also cause the server to perform poorly
and eventually run out of memory.
This practice uses a sample Web application that triggers some data allocation onto the Java
heap. The JVM heap size is configured iteratively to best address performance needs.
User credentials
Username
Password
weblogic
Welcome1
Domain configuration
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001
Managed Server
mainserver
localhost
7003
The JRockit Management Console is used to manage and monitor the JRockit JVM. You can
monitor memory, CPU, heap, and GC information.
1. Set up the practice domain (ptcourse) and deploy the practice application.
a. Launch gnome-terminal and run the following command:
b. Change the working directory to <CURRENT_PRACTICE>

(~/wls11g_tune/labs/lab03_01) and execute the setup command:
$> cd ~/wls11g_tune/labs/lab03_01
$> ant setup_ptdomain
2.
Start the Administration Server, for the ptcourse domain. Then set the Xmanagement
option and start the main server (the managed server in the ptcourse domain). Then
using the Administration Console, deploy it using the JRockit JVM with the -Xmanagement
option turned ON.
a. In the gnome-terminal, run the start_ptadm.sh script from the exercise subfolder.
$> cd ~/wls11g_tune/labs/lab03_01/exercise
$> gnome-terminal e ./start_ptadm.sh
b.
Run deploy_StockApp.py in WLST.

$> java weblogic.WLST deploy_StockApp.py

Chapter 3 - Page 3
Practice 3-1: Monitoring and Tuning Oracle JRockit JVM
Set the JAVA_VENDOR and JAVA_OPTIONS environment variables using the following
commands:
$> export JAVA_VENDOR="Oracle"
$> export JAVA_OPTIONS="$JAVA_OPTIONS -Xmanagement"
d.
Start the managed server mainserver by invoking the following command:

$> ./start_ptmain.sh
3.
Note the following message on the terminal window for mainserver:

[Info] [mgmt] Local JMX Connector started.
Start the JRockit Management Console.
a. In a new gnome-terminal, determine which process is running mainserver by using
the following command:
$> ps ef | grep mainserver
b.
Run the course environment setup script and then start Oracle JRockit Mission Control
using the following commands:
$> $MW_HOME/jrockit_160_17_R28.0.0-679/bin/jrmc
c.
In the JVM browser of Oracle JRockit Mission Control running, right-click the instance
with the process number that is running mainserver, and click Start Console.

Chapter 3 - Page 4
c.
4.
On the Runtime page, click the Memory tab and note the Garbage Collection strategy
currently being used.
Run the stress test using The Grinder.

a. Using a text editor, inspect the URL and Port values in The Grinder scripts
grinder.properties, and httpscript.py in
$HOME/wls11g_tune/labs/lab03_01/grinder.
b. Set up The Grinder environment.
c.
Run a stress test by invoking The Grinder by using the following command:
java net.grinder.Grinder grinder.properties
Note: You are not using The Grinder Console because you are only simulating some load
on the server and not looking at the response time or throughput for now.

Chapter 3 - Page 5
d.
Use the JRockit Management Console to note the GC strategy.

a. Go to the JRockit Management Console while The Grinder is generating some load on
the server. Go to the Memory tab to see the Garbage Collection strategy changing
automatically.
Note: The dynamic collector configured for a specific heuristic (default: throughput) will
automatically change the GC strategy to meet the specified goal. To notice such a
change may be a bit challenging because of variation in resources (especially the
number of CPUs, bit-size of the OS, and the memory available) on the machines
classroom environments.
Note: You may also have to simulate higher load on the system by increasing the
number of threads say 10 times, and number of runs in the grinder.properties file.
Note: However after the preferred strategy has been selected, you will not see any
more changes.
b. Close the JRockit Management Console after you have finished inspecting the various
tabs.
c. If The Grinder did not stop on its own, kill the process by using Ctrl + C.
Note: The stress test may cause the mainserver to run out of memory. If it does, kill
the mainserver process (kill -9 <PID>).

Chapter 3 - Page 6
5.
An application has just been developed and you have the task to deploy it and do performance
testing before it goes live.
To be able to test your application, you have developed a simple driver that will simulate the
market and the client. The goal is to be able to handle 100,000 messages per second with a
good response time.
You performed the tests by using the JFR, and recorded the performance metrics. All
associated JFR recordings are located in the JFR_RECORDINGS subfolder and named with
the corresponding number of the section they are associated with.
1. Without much tuning information, you had started up the server with the parameters in the
development environment. The results are in the JFR_RECORDINGS folder as 1.jfr. Try
to analyze the results and discuss them in the classroom.
a. Invoke jrmc. Using File > Open files, bring up the File Open window.
b.
In the Open File window, navigate to the wls11g_tune/labs/JFR_RECORDINGS

folder, select JFR recoding (*.jfr), and then select the 1.jfr file

Chapter 3 - Page 7
Practice 3-2: Analyzing Recorded JRockit Flight Recorder Sessions
The Open Window appears as follows:
d.
Navigate to the CPU/Threads page and notice that the CPU usage is generally well
over 90%.
e.
Navigate to the Memory page and notice the memory allocation, heap usage, and
garbage collection statistics
1) What are the values for initial and maximum allocations? (256 MB)
2) How many garbage collections have been completed in about 1 minute? (401)
3) What is the average pause time for garbage collection? (66.929 ms)
4) What is the total time spent in pause due to garbage collection? (401 * 66.929 ms
~ 27 sec)

Chapter 3 - Page 8
c.
2.
Based on your observation, what would be the best suggestion to improve

performance?
1) Change GC to Generational Parallel GC to get more frequent but short young
collections. (Switching to a generational GC with the heap size the same would not
help in this case. The amount of live data on the heap is almost filling up the 256
MB, which leaves very little room for a nursery.)
2) Increase Heap Size to lessen the GC frequency (The heap is almost full and
you spend a lot of time just doing GC. Increasing the heap size will allow
more space for allocation and decrease the GC frequency. Consequently,
this gives enough room for the application to run.)
3) Decrease Heap Size to get more frequent but hopefully short garbage collections.
(With the heap almost full, reducing the heap further would lead to even more
frequent GC and if reduced even further to Out-Of-Memory errors.)
With the insight that the first issue was a too small heap, you increase the heap size and
restart the benchmarking. The results are recorded in 2.JFR. Now analyze the results.
a.
b.
c.
d.
e.
In your Mission Control session, close all other views and load 2.JFR from the
wls11g_tune/labs/JFR_RECORDINGS folder.
Navigate to the CPU/Threads page and notice that the CPU usage is generally well
under 30%.
Navigate to the Memory page and notice the memory allocation, heap usage, and
garbage collection statistics.
1) What are the values for initial and maximum allocations? (2 GB)
2) How many garbage collections have been completed in about 1 minute? (86)
3) What is the average pause time for garbage collection? (86.794 ms)
4) What is the total time spent in pause due to garbage collection? (~7 sec)
5) Navigate to the GC Graph tab on the Memory page and note which generation is
affected mostly in garbage collection. (Old Generation)
Navigate to the Overview page and notice the average value of heap fragmentation
(30.31%) and average pause time for garbage collection (86.794 ms).
You want to reduce the heap fragmentation as well as pause time in garbage
collection. What configuration change should help reduce the heap fragmentation?
1) Change from a single GC to a generational GC. (For this application, the best
choice is to switch to a generational GC. Using a nursery results in an
indirect compaction because short-lived objects are never copied to the old
space reducing the risk of short-lived and long-lived objects residing next to
each other.)

Chapter 3 - Page 9
f.
f.
Increase the compaction ratio. (In several cases, increasing compaction will help
reduce fragmentation. The JFR shows that JRockit is compacting 128 MB each
GC. However, for this application, the allocation pattern is so mixed that this is not
enough. Increasing the area would reduce the fragmentation, but for this
application, it would not be enough).
3) Reduce the compaction ratio. (Compaction is how JRockit can reduce
fragmentation on the heap. Reducing the ratio would have the effect of further
increasing fragmentation.)
Now analyze the results by using 3.JFR from the
wls11g_tune/labs/JFR_RECORDINGS folder.

Chapter 3 - Page 10
2)
Chapter 4
Chapter 4 - Page 1
Practices Overview
are using.

Chapter 4 - Page 2
Monitor the Sun HotSpot JVM by using Java VisualVM
Tune HotSpot JVM garbage collection
Design
Overview
This practice uses a sample Web application that triggers some data allocation onto the Java
heap. The challenge of this practice is to monitor and tune the performance of the HotSpot JVM
so that the application performance is improved.
Specifications
User credentials
Username
Password
weblogic
Welcome1
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001
Managed Server
mainserver
localhost
7003
JMS resources
Type
Name
Target
JMS Server
PTJMSServer
mainserver
JMS Module
PTJMSModule
mainserver
Type
Name
JNDI Name
JMS ConnectionFactory
PTConnectionFactory
jms.PTConnectionFactory
JMS Queue
PTQueue
jms.PTQueue
Performance statistics
Settings
Successful
Tests
Errors
Mean Time
(ms)
Xms64m Xmx256m
Xms256m Xmx512m

Chapter 4 - Page 3
Transactions
Per Second
Practice 4-1: Monitoring and Tuning HotSpot JVM
Note: If you have not already performed Part A in Practice 3, ensure that you have performed
steps 1 and 2 in Part A of Practice 3 before beginning this practice.
1. Stop all the servers in ptcourse domain.
a. Launch the gnome-terminal and run the course environment setup script.
b.
2.
Change the working directory to /home/oracle/wls11g_tune/labs/lab04_01,

and stop the main server and the administration server:
$> ./exercise/stop_ptmain.sh
$> ./exercise/stop_ptadm.sh
Set the JAVA_VENDOR environment variable to Sun. Start the Administration Server for
ptcourse. Set the JAVA_OPTIONS as indicated in the following table and then start the
managed server.
Variable
a.
Value
JAVA_VENDOR
Sun
USER_MEM_ARGS
-Xms64m Xmx256m XX:MaxPermSize=128m
JAVA_OPTIONS
-Dcom.sun.management.jmxremote
Invoke a gnome-terminal. Navigate to

/home/oracle/wls11g_tune/labs/lab04_01/exercise folder. View the
start_ptadm_04.sh and start_ptmain_04.sh scripts. Note the setting of
JAVA_VENDOR, USER_MEM_ARGS, and JAVA_OPTIONS environment variables.
start_ptadm_04.sh is shown here. You can also view start_ptmain_04.sh.
$> cat start_ptadm_04.sh
export PRODUCTION_MODE="true"
export DOMAIN_HOME=/u01/app/work/domains/ptcourse
export JAVA_VENDOR="Sun"
export USER_MEM_ARGS="-Xms64m -Xmx256m -XX:MaxPermSize=128m"
export JAVA_OPTIONS="$JAVA_OPTIONS Dcom.sun.management.jmxremote Djavax.management.builder.initial=weblogic.management.jmx.mbeans
erver.WLSMBeanServerBuilder"
${DOMAIN_HOME}/bin/startWebLogic.sh
$>
b.
Use the following commands to start adminserver and mainserver.

$> gnome-terminal -e "./start_ptadm_04.sh" --title "PT Admin"
$> gnome-terminal -e "./start_ptmain_04.sh" --title "PT Main"
3.
Start Java VisualVM and monitor the performance of the mainserver JVM.
a. Start Java VisualVM by invoking the following command in a gnome-terminal: (Note:
When you start the Java VisualVM for the first time, you may get the Calibration will be

Chapter 4 - Page 4
Part A: Monitoring the Sun HotSpot JVM by Using Java VisualVM

$> $MW_HOME/jdk160_18/bin/jvisualvm &
4.
b.
Determine the pid for the mainserver by executing the following command in the
gnome-terminal window:
$> ps ef | grep java | grep mainserver
c.
Double-click weblogic.Server with the pid for mainserver to open the monitoring
page for mainserver.
View details on the Overview and Monitor tabs.

a. Confirm that the Xmx and Xms values are as you intended.
b. Confirm that the main server is running on port 7001.

Chapter 4 - Page 5
performed message box. Click OK.
5.
Access the Monitor tab and notice the graphs relating to CPU and memory (heap)
usage.
Run a stress test by using The Grinder, and monitor the CPU and memory usage graphs in
Java VisualVM.
a. At the prompt, change the working directory to:
$HOME/wls11g_tune/labs/lab04_01/grinder
$> cd $HOME/wls11g_tune/labs/lab04_01/grinder
b.
Open The Grinder scripts grinder.properties, httpscript.py, and

httpscript_tests.py by using a text editor. Inspect the URL and Port values.
c.
Set up The Grinder environment by using the setEnv.sh script.

d.
Run a stress test by invoking The Grinder using the following command:
java net.grinder.Grinder grinder.properties
Note: You are not using The Grinder Console because you are just simulating some load
$> java net.grinder.Grinder grinder.properties
e.
You can also use Java VisualVM to visualize the CPU and memory usage. Notice
that the CPU usage is at near 100% at times, while the used heap space reaches
100% most of the time. Also you may get occasional "Out of memory" errors in the PT

Chapter 4 - Page 6
c.
f.
View the performance results from log files.
Part B: Tuning the Java Heap Size

In this practice different heap size values are used for start (-Xms) and maximum (-Xmx) in the
provided scripts. After performing each test with one set of variables (for example -Xms256m Xmx512m), you can edit the scripts mentioned in this practice to configure -Xmx and -Xms
values to be the same (for example -Xms512m -Xmx512m). Then start up the managed servers
with revised parameters and perform your test.
6. Restart the Managed Server instance with USER_MEM_ARGS="-Xms256m Xmx512m".
a.
Navigate to the $HOME/wls11g_tune/labs/lab04_01/exercise folder. Stop

monitoring mainserver and then stop mainserver by using the stop_ptmain.sh
script. Enter the username (weblogic) and password (Welcome1) when prompted.
$> cd $HOME/wls11g_tune/labs/lab04_01/exercise
$> stop_ptmain.sh
b.
View start_ptmain_256.sh in the

$HOME/wls11g_tune/labs/lab04_01/exercise folder and note the memory
(heap size) allocation.
...
$> export USER_MEM_ARGS="-Xms256m Xmx512m XX:MaxPermSize=128m"
...
c.
Start mainserver by using the start_ptmain_256.sh script.

Chapter 4 - Page 7
Main window.
d.
Navigate to the grinder subfolder under lab04_01 and run the test again.
e.
Connect to the new managed server instance in JVisualVM and verify the CPU and
Memory usage now. Notice that the CPU usage is rarely at 100%, and also the used
heap size is generally well below the maximum.
f.
7.
Verify the values recorded in the three output (out_*.log) files in

/u01/app/work/Hotspot_Results folder.
Now perform the tests using 512m of heap size (USER_MEM_ARGS="-Xms512m Xmx1g
XX:MaxPermSize=256m").
a. Stop mainserver.
b.
Start mainserver by using the following command

$> gnome-terminal -e "../exercise/start_ptmain_512.sh" --title
"PT Main 512"
c.
Navigate to the grinder subfolder under lab04_01, and run the test again.
d.
Now monitor the mainserver JVM by using JVisualVM and notice that the CPU usage
is mostly well below 50% and the heap usage is also never at 100%.

Chapter 4 - Page 8
$> gnome-terminal e "./start_ptmain_256.sh" -title "PT Main

256"
By analyzing the test results noted for the different memory settings, specify which
setting will be optimal for better response time and throughput.

Chapter 4 - Page 9
e.
Chapter 4 - Page 10
Chapter 5
Chapter 5 - Page 1
Practices Overview
This practice was developed and tested using a machine with one CPU and 2GB of RAM. The
are using.

Chapter 5 - Page 2
In this practice, you do the following:
Create a global Work Manager
Create a global request class and global constraint

Assign a request class and constraint to Work Manager
Assign a Work Manager to a Web application
Create and assign a Work Manager at the application level

Compare Work Managers
Design
Overview
Mission-critical applications need a higher priority than other applications deployed on the same
server. The WebLogic Server allows you to configure how your application prioritizes the
execution of its work by using rules that you define and by monitoring the actual run-time
performance. You define the rules and constraints for your application by defining a Work
Manager and applying it either globally to a WebLogic Server domain or to a specific application
component.
In this practice, you use two Web applications: BrowseMarketApp and BrowseStoreApp.
You assign to BrowseMarketApp a low priority Work Manager having a low fair share, and to
BrowseStoreApp a high priority Work Manager having a high fair share.
During a period of sufficient demand when the number of requests for each application exceeds
the number of threads, the WebLogic Server allocates a higher thread-usage time to
applications (BrowseStoreApp) with a higher priority.
mainserver
Domain: ptcourse
Port: 7003
Work Manager: lowPriority

Fair Share Request Class:
lowFairShare
Constraint: maxThreads
BrowseMarketApp
adminserver
Port: 7001
BrowseStoreApp
Work Manager: highPriority

Fair Share Request Class:
highFairShare
Constraint: maxThreads
User credentials
Username
Password
weblogic
Welcome1

Chapter 5 - Page 3
Practice 5-1: Using Work Managers
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001
Managed Server
mainserver
localhost
7003
Performance statistics: preconfiguration (Applications using default Work Manager)

Metric
Mean Test
Time (ms)
Successful Tests Errors
BrowseMarketApp
391.48
4500
BrowseStoreApp
462.97
4500
Performance statistics: Postconfiguration (Applications using Work Managers High

Priority and Low Priority)
Metric
Mean Test Time Successful Errors

(ms)
Tests
BrowseMarketApp (Low Priority)
496.92
4500
BrowseStoreApp (High Priority)
273.70
4500
1.
Reset the ptcourse domain and then start adminserver and mainserver.
a.
If any servers of ptcourse domains are running, stop those servers.
b.
Invoke a gnome-terminal window and run set_course_env.sh in the

~/wls11g_tune/bin folder.
c.
In the same window, navigate to ~/wls11g_tune/labs/lab05_01. Then run the

Ant script setup_ptcourse.
d.
Start adminserver and mainserver.

$> start_ptadm.sh
$> start_ptmain.sh
e.
Deploy the applications by using the deploy.py WLST script in

~/wls11g_tune/labs/lab05_01/exercise/WLSTScripts.
$> cd ./exercise/WLSTScripts
$> java weblogic.WLST deploy.py
f.
Verify and test the applications by opening a Web browser and navigating to
http://localhost:7003/BrowseStoreApp/ and
http://localhost:7003/BrowseMarketApp/.

Chapter 5 - Page 4
Run a stress test using by The Grinder. At this point, there is no Work Manager assigned to
either of the applications. Therefore, they use the default Work Manager. In this section, it
would be useful to run The Grinder for both applications simultaneously.
a. Invoke two new gnome-terminal windows. In one gnome-terminal, change the working
directory to ~/wls11g_tune/labs/lab05_01/grinder/HP. In the other, change
the working directory to wls11g_tune/labs/lab05_01/grinder/LP.
In the first session:

$> cd ~/wls11g_tune/labs/lab05_01/grinder/HP
In the second session:

$> cd ~/wls11g_tune/labs/lab05_01/grinder/LP
b.
In both sessions, set up the course environment and The Grinder environment.
$> source ../setEnv.sh
c.
In both sessions, run the stress test by invoking The Grinder using the following
command:
Note: You are not using The Grinder Console because you are just simulating some load
d. Watch the agent windows while the threads start running. When both Grinder agents
have finished running all threads, two new directories called WM_HP_Results and
WM_LP_Results are created in the /u01/app/work directory.
e.
3.
Open the out_<machine-name>.log file that is in the WM_HP_Results directory,

and open the out_<machine-name>.log file that is the WM_LP_Results directory.
Scroll down in the files to find the Performance statistics: preconfiguration table, and
record the following results in the table.
1) Mean Test Time (ms)
2) Total tests successfully executed
3) Errors (if any)
Create a global Work Manager named lowPriority and target it to mainserver.
a.
4.
b.
c.
d.
e.
f.
Open a Web browser and navigate to http://localhost:7001/console/ and log

in as weblogic (password: Welcome1).
Click Lock & Edit in the Change Center.
In Domain Structure, navigate to ptcourse > Environment > Work Managers.
In Summary of Work Managers, click New.
Select Work Manager. Click Next.
Enter lowPriority for Name. Click Next.
g.
Target the mainserver. Click Finish. Then click Activate changes.
Create a global request class named lowFairShare and target it to mainserver.

Note: After you have created a global Work Manager, you must create at least one request
class or constraint and assign it to the Work Manager to schedule work.
a. In Domain Structure, navigate to ptcourse > Environment > Work Managers.
b. Click Lock & Edit to initiate configuration changes. In Summary of Work Managers,
click New.

Chapter 5 - Page 5
2.
Select Fair Share Request Class. Click Next.

Enter lowFairShare for Name. Click Next.
e.
Target the mainserver. Click Finish.
Create a global constraint named maxThreads and target it to mainserver.

b. In Summary of Work Managers, click New.
c. Select Maximum Threads Constraint. Click Next.
d. Enter maxThreads for Name.
e.
f.
g.
6.
Enter 25 for Count.

Leave Data Source empty. Click Next.
Target the mainserver. Click Finish.
Assign the lowFairShare request class and the maxThreads constraint to the
lowPriority Work Manager.
b. Click lowPriority.
c.
7.
Select lowFairShare as the Request Class.
d. Select maxThreads for Maximum Threads Constraint.

e. Click Save.
f. Activate Changes in the Change Center.
Create a global request class named highFairShare.
Note: We will use this request class with an application-level work manager.
b. If required, click Lock & Edit to initiate configuration changes. In Summary of Work
Managers, click New.
c. Select Fair Share Request Class. Click Next.
d. Enter highFairShare for Name and 800 for Fair Share value, and click Next.
e.
Do not select any server as target and click Finish.


Chapter 5 - Page 6
5.
c.
d.
Assign the global Work Manager lowPriority to the BrowseMarketApp application.
a. In the gnome-terminal window, navigate to

/home/oracle/wls11g_tune/labs/lab0501/exercise/applications/BrowseMarketApp/WEB-INF directory.
b.
Open the deployment descriptor, weblogic.xml, by using a text editor. Insert the
following line to reference the lowPriority Work Manager, and then save and
close the file:
<wl-dispatch-policy>lowPriority</wl-dispatch-policy>
c.
9.
In the Administration Console, click Lock & Edit in Change Center. Then navigate to
ptcourse > Deployments in the domain structure.
d. In Summary of Deployments, select the BrowseMarketApp check box and click
Update.
e. Accept the defaults and click Finish.
f. Activate the changes in the Change Center.
g. Open a Web browser and navigate to http://localhost:7003/BrowseMarketApp/.
Browse to make sure that the application is running.
Create and assign an application-level Work Manager named highPriority for the
BrowseStoreApp application.
a. In Admin Console Domain Structure, navigate to ptcourse > Deployments. Then click
the BrowseStoreApp link in the table.
b. Navigate to Configuration > Workload and notice that there are no application-scoped
work managers.
c. Click Lock & Edit in the Change Center. Then click New in the Application Scoped
Work Managers table.
d. In the Create a New Work Manager Component wizard, enter highPriority as the
name and click Finish.
e. The Save Deployment Plan Assistant appears. In the Path field, enter
/home/oracle/wls11g_tune/labs/lab05_01/exercise/applications/HP_
Plan.xml. Then click OK. You will receive a message indicating deployment plan has
been created.
f. Now you can assign the previously created highFairShare class to highPriority
work manager. Click highPriority link in Application Scoped Work Managers.
g.
In the Settings for highPriority, select highFairShare as the Request Class. Also
select maxThreads as the Maximum Threads Constraint. Then click Save. A

Chapter 5 - Page 7
8.
h.
Click Release Configuration in Change Center.

Note: Since we have only assigned highPriority work manager to BrowseStore
application, but have not created a dispatch policy for the same, the BrowseStore
application continues to use the default work manager that is used by the managed
server.
Note: You can assign highPriority work manager to Main server, and then you will
notice that the BrowseStore application also uses highPriority work manager.
10. Run a stress test again by using The Grinder.
a. Repeat step 2 and record the new results into the Performance Statistics:
postconfiguration table.
11. Review the results and compare the results collected in the Performance Statistics table.

Chapter 5 - Page 8
"Deployment plan has been successfully updated" confirmation message appears.
Chapter 6
Chapter 6 - Page 1
Practices Overview
There is no practice for Lesson 6.

Chapter 6 - Page 2
Chapter 7
Chapter 7 - Page 1
Practices Overview
are using.

Chapter 7 - Page 2
Use the JavaServer Pages (JSPs) compiler weblogic.jspc to precompile JSPs
Improve performance by disabling page check
Design
Overview
A Web application with several JavaServer Pages (JSPs) seems to be running slow. Web
pages take time to load on a browser when the user clicks a link or a button.
Whenever a request is made for a JSP, the WebLogic Sever translates the JSP into a servlet,
compiles the servlet code, and then serves the request. Performance of JSPs can be improved
by precompiling the JSPs, thereby avoiding the overhead for the server to compile.
In addition, the WebLogic Server can be tuned not to check to see if the JSPs have changed.
Domain configuration used in this practice:
mainserver
Domain: ptcourse
Port: 7003
adminserver
Port: 7001
StockWatcherzApp
User credentials
Username
Password
weblogic
Welcome1
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001
Managed Server
mainserver
localhost
7003
Performance statistics: preconfiguration

Metric
Mean Test Time (ms) Successful Tests Errors
StockWatcherzApp 1241.26
28000

Chapter 7 - Page 3
Overview of Practice 7-1: Tuning JSP
Metric
28000
Performance statistics: page check disabled

Metric
1.
Set up the practice domain (ptcourse) and deploy the practice application.
a. Launch the gnome-terminal and run the following command:
b.
2.
28000
Change the working directory to ~/wls11g_tune/labs/lab07_01 and execute the

setup command:
$ cd ~/wls11g_tune/labs/lab07_01
Start the Administration Server and mainserver in ptcourse. Then deploy StockApp.
a.
Start the Administration and Managed servers in the ptcourse domain.

$> start_ptadm.sh
$> start_ptmain.sh
b.
Deploy the StockWatcherz application by using WLST as shown here:

$> cd exercise/WLSTScripts
c.
3.
Verify the application by navigating to

http://localhost:7003/StockWatcherzApp/ in your Web browser.
Run a stress test using The Grinder. Then note the test result values for mean time,
successful runs, and errors.
a. In the gnome-terminal, navigate to the ~/wls11g_tune/labs/lab07_01/grinder
folder and set up the environment variables for Grinder.
b.
Run a stress test by using the following command:

$> java net.grinder.Grinder grinder.properties.
c.
Watch the agent window while the threads start running.

When The Grinder agent has finished running all threads, a new directory called
JSP_Results is created in the /u01/app/work directory.
d.
Open the out_<system>.log file that is in the newly created directory, and scroll
down to record the following results in the Performance statistics: preconfiguration
table:
3) Errors (if any)

Chapter 7 - Page 4
Performance statistics: precompiled JSPs
Precompile the StockWatcherzApp Web application by using weblogic.appc. Then

rename the old StockWatcherzApp to uncompiledApp and the compiledApp folder to
StockWatcherzApp.
a. In a gnome-terminal, set up the course environment variables.
$ source set_course_env.sh
b.
Navigate to
home/oracle/wls11g_tune/labs/lab07_01/exercise/applications folder
and execute the following command to compile the application:
$> java
weblogic.appc
-output ./compiledApp
./StockWatcherzApp/
c.
Now list the files in ./compiledApp/WEB-INF/classes/jsp_servlet folder.

$> cd ./compiledApp/WEB-INF/classes/jsp_servlet
$> ls
__browsestore.class __glossary.class __loggedoff.class
__shoppingcart.class __viewshoppingcart.class
__footer.class
__header.class
__loggingoff.class
__shopping.class
__welcome.class
d.
5.
Using the mv Linux command, rename the folders as follows:

$> cd ~/wls11g_tune/labs/lab07_01/exercise/applications
$> mv ./StockWatcherzApp ./uncmpiledApp
$> mv ./compiledApp ./StockWatcherzApp
Using the Administration Console, delete the deployed StockWatcherzApp.

a. Click Lock & Edit in Change Center of Administration Console.
b. Navigate to ptcourse > Deployments. In the Summary of Deployments, select
(check box) StockWatcherz application and click Stop > Force Stop Now. Then click
Yes to confirm.
c. When the StockWatcherzApp application reaches the "Prepared" state, select the
application and click Delete. Then click Yes to confirm deletion.
d. Click Activate Changes in the Change Center.
e. Deploy new StockWatcherzApp using WLST as follows:
$> cd ../WLSTScripts
6.
7.
Run the stress test again by using The Grinder.

a. Repeat step 3 and record the new results in the Performance statistics: precompiled
JSPs table.
Disable Page Check.
a. In the gnome terminal navigate to the

~/wls11g_tune/labs/lab07_01/exercise/applications/StockWatcherzA
pp/WEB-INF folder.
$> cd
~/wls11g_tune/labs/lab07_01/exercise/applications/StockWatcherzA
pp/WEB-INF

Chapter 7 - Page 5
4.
Edit weblogic.xml with a text editor and disable page check seconds by changing
the value to -1 as shown. Save and close the file.
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<jsp-descriptor>
<page-check-seconds>-1</page-check-seconds>
</jsp-descriptor>
</weblogic-web-app>
c.
d.
8.
Using the Administration Console, update the application.

Open a Web browser and navigate to
http://localhost:7003/StockWatcherzApp/.
Run the stress test using The Grinder.
a. Repeat step 3, but this time, run stressTest twice. This eliminates some initialization
from the results. Record the second run results in the Performance statistics: page
check disabled table.
b. Review and compare the results collected in all the Performance statistics tables.

Chapter 7 - Page 6
b.
Chapter 8
Chapter 8 - Page 1
Practices Overview
are using.

Chapter 8 - Page 2
Tune connection pool settings in a data source
Improve performance by using the statement cache
Overview
A Web application with a lot of database interaction seems to be running slow. The WebLogic
Server creates connections as and when required. Every JDBC query that is executed is
compiled and then executed.
Whenever a new connection is needed, the WebLogic Server creates a new connection by
going to the database. This takes some time, which can vary based on the database. In
production environments, this can be avoided by creating all these connections at startup. In
addition, JDBC queries can be cached to save precious compile time. Pinned-To-Thread is an
option that can improve performance by enabling execute threads to keep a pooled database
connection even after the application closes the logical connection.
Domain configuration used in this practice:
Domain: ptcourse
MedRecSvr1
Port: 7021
Oracle
Database:
orcl
DataSource:
MedRecDS
Schema
medrec
MedRecAdmSvr
Port: 7020
medrec
application
User credentials
Username
Password
weblogic
Welcome1
Type
Name
Address
Port
Admin Server
MedRecAdmSvr
Localhost
7020
Managed Server
MedRecSvr1
Localhost
7021

Chapter 8 - Page 3
Practice 8-1: Monitoring and Tuning JDBC
Metric
Mean Test Time (ms)
Successful Tests
Errors
medrec application
Connections in pool: Initial = 15 and Maximum = 15
Metric
Mean Test Time (ms)
Successful Tests
Errors
Successful Tests
Errors
medrec application
Performance statistics: Statement caching
Metric
Mean Test Time (ms)
medrec application
Statement cache: Type = LRU, Size = 10 and Pinned-to-Thread, enabled
Metric
Mean Test Time (ms)
Successful Tests
Errors
medrec application
Statement cache: Type = LRU, Size = 35 and Pinned-to-Thread, enabled
Metric
Mean Test Time (ms)
Successful Tests
Errors
medrec application
1.
2.
Set up the medrec domain and deploy the practice application. Then start up the
administration server and one managed server.
a. Launch the gnome-terminal and set up the course environment variables by running
the following command:
b.
Change the working directory to ~/wls11g_tune/labs/lab08_01 and set up the

MedRec domain:
$> ant setup_medrec
c.
When the MedRecSvr1 server starts up, enter the username (weblogic) and
password (Welcome1).
d.
In a Web browser window, access the URL: http://localhost:7021/medrec.
e. Log in to the application as a patient (fred@golf.com) with the password weblogic.

Verify the connection pools Initial and Maximum Capacity.
a. To access the Administration Console of MedRec domain, open a Web browser and
navigate to http://localhost:7020/console. Log in as weblogic/Welcome1.
b. In Domain Structure, navigate to MedRecDomain > Services >JDBC > Data Sources.
c. Click MedRecGlobalDataSourceXA. (This has been preconfigured in the medrec
domain.)

Chapter 8 - Page 4
Connections in pool: Initial = 5 and Maximum = 15
3.
Click Connection Pool. Verify that the initial capacity is 5 and the maximum capacity is
15.
Run the stress test by using The Grinder.
folder and set up the environment variables for The Grinder.
b.
Run the stress test by using the following command:

c.
Watch the agent window while the threads start running. When The Grinder agent has
finished running all threads, the DS_Test_Logs folder containing the files of stress
test is created in the /u01/app/work folder.
d.
4.
5.
Open the out_<system>.log file from the newly created directory and scroll down to
record the following results in the Performance statistics table (Connections in Pool:
Initial = 5 and Maximum = 15).
3) Errors (if any)
Change the connection pools Initial and Maximum Capacity.
a. Access the Administration Console for Medrec domain
(http://localhost:7020/console).
b. In the Change Center, click Lock & Edit. In Domain Structure, navigate to
MedRecDomain> Services >JDBC > Data Sources.
c. Click MedRecGlobalDataSourceXA.
d. Click Connection Pool. Change the number of physical connections in the pool to:
Parameter
Value
Initial Capacity
15
Maximum Capacity
15
e. Click Save. Then click Activate Changes in the Change Center.

Run the stress test again by using The Grinder, and record the new results in the
Performance statistics table (Connections in Pool: Initial = 15 and Maximum = 15).
a. Stop MedRec Server 1 by using the stop_mr1.sh script or by keying CTRL + C in
the MedRec Server 1 window.
$> stop_mr1.sh
b.
Start MedRec Server 1 by using the start_mr1.sh script.

$> start_mr1.sh
c.
6.
Repeat step 3 and record the new results in the Performance statistics table
(Connections in Pool: Initial = 15 and Maximum = 15).
Change the statement cache size to 10 and enable Pinned-to-Thread.
a. In Domain Structure, navigate to MedRecDomain > Services >JDBC > Data Sources.
b. Click MedRecGlobalDataSourceXA.
c. Click Connection Pool. Change the number of physical connections in the pool back to:

Chapter 8 - Page 5
d.
Value
Initial Capacity
Maximum Capacity
15
Verify the Statement Cache parameters:

Parameter
Value
Statement Cache Type
LRU
Size
10
e.
f.
7.
Click Save.
Click Advanced to change advanced parameters, and select the Pinned-to-Thread
check box.
Note: The Pinned-to-Thread option can improve performance by enabling execute
threads to keep a pooled database connection even after the application closes the
logical connection.
g. Click Save.
Run the stress test again by using The Grinder, and record the new results in the
Performance statistics table (Statement Cache: Type = LRU, Size = 10 and Pinned-toThread, enabled).
a. Stop MedRec Server1 by using the stop_mr1.sh script.
$> stop_mr1.sh
b.
Start MedRec Server1 by using the start_mr1.sh script.

$> start_mr1.sh
c.
8.
Repeat step 3 (to run the stress test) and record the new results in the Performance
statistics table (Statement Cache: Type = LRU, Size = 10 and Pinned-to-Thread,
enabled).
Increase the statement cache size to 35 and run the stress test again by using The Grinder.
Record the new results in the performance statistics table (Statement Cache: Type=LRU,
Size = 35 and Pinned-to-Thread, enabled).
a. Using step 6 as a guide, change the statement cache size to 35.
b. Repeat step 3 and record the new results in the Performance statistics table
(Statement Cache: Type = LRU, Size = 35 and Pinned-to-Thread, enabled).
c. Review and compare the results collected in all the Performance statistics tables.

Chapter 8 - Page 6
d.
Property
Chapter 9
Chapter 9 - Page 1
Practices Overview
are using.

Chapter 9 - Page 2
In this practice, you change the size of the initial-beans-in-free-pool to improve the
initial response time of the stateless session EJBs.
Overview
You are provided with a sample enterprise application involving a Web application that invokes
a stateless session and an EJB to get a quote. Initial benchmarking revealed that the application
is performing slowly.
Stateless session beans provide nonconversational services. They do not maintain state on
behalf of clients and are synchronous. They are maintained in memory by the EJB container. A
container can pool stateless session EJBs that different clients can reuse. You can improve
performance by tuning the size of the stateless session EJB pool.
mainserver
Domain: ptcourse
Port: 7003
adminserver
InsuranceApp
Port: 7001
InsuranceEJB
User credentials
Username
Password
weblogic
Welcome1
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001
Managed Server
mainserver
localhost
7003
Performance statistics: Initial Beans in Free Pool = 1

Metric
InsuranceApp
Performance statistics: Initial Beans in Free Pool = 15 (or any custom value)
Metric
InsuranceApp
1.

Chapter 9 - Page 3
Practice 9-1: Tuning EJB
b.
2.

setup command:
Start the Administration Server, and mainserver in ptcourse. Then deploy

InsuranceApp applications.
a.

$> start_ptadm.sh
$> start_ptmain.sh
b.
Navigate to exercise/WLSTScripts subfolder and deploy the InsuranceApp

application.
$> cd exercise/WLSTScripts
c.
3.
4.
Verify and test the application by opening a Web browser and navigating to
http://localhost:7003/EJBClient
Verify the configuration for the Initial Beans in the Pool count.
a. Open a Web browser and navigate to http://localhost:7001/console. Log in
as weblogic/Welcome1.
b. In Domain Structure, navigate to ptcourse > Deployments. In the deployments table,
click InsuranceApp.
c. In Modules and Components, click Insurance.
d. Click the Monitoring tab and verify that the value for the Pooled Beans Current Count =
1.
Run a stress test by using The Grinder.
b.

c.
finished running all threads, the EJB_Results folder containing the files of the stress
d.
5.
record the following results in the Performance statistics table.
3) Errors (if any)
Redeploy the InsuranceApp application with a deployment plan that sets the initialbeans-in-free-pool to 15.

Chapter 9 - Page 4
a.
b.
c.
Open a Web browser and navigate to http://localhost:7001/console. Log in

as weblogic/Welcome1.
In the Change Center, click Lock & Edit.
In Domain Structure, navigate to ptcourse > Deployments. Then select InsuranceApp
in the Deployments table and click Update.
d.
In the Update Application Assistant wizard step, click Change Path in the Deployment
plan path field.
e.
In the next step, locate plan_with_15_init.xml in the

/home/oracle/wls11g_tune/labs/lab09_01/exercises/applications

Chapter 9 - Page 5
Note: The value of 15 is not a benchmark value. You can achieve a performance increase
by increasing the initial bean size to a value higher than 1.
f.
6.
7.
In the next step, ensure that Redeploy this application using the following deployment
files is selected and then click Finish.
g. In the Change Center, click Activate Changes.
Verify the Initial Beans in the Free Pool count.
a. In Domain Structure of the Administration Console, navigate to ptcourse >
Deployments.
b. Click InsuranceApp.
c. In Modules and Components, click Insurance.
d. Click the Monitoring tab and verify that the value for the Pooled Beans Current Count =
15.
e. Open a Web browser and navigate to http://localhost:7003/EJBClient.
Repeat the stress test by using The Grinder.
a. Repeat step 4 and record the new results in the Performance statistics: Initial Beans in
Free Pool = 15 table.

Chapter 9 - Page 6
folder. Then click Next.
Chapter 10
Chapter 10 - Page 1
Practices Overview
are using.

Chapter 10 - Page 2
Understand the various disk write policies for writing to a file store
Tune the file persistence store for persisting JMS messages
Overview
Addressing the performance of a messaging system in a very generic manner on the WebLogic
Server is very difficult. Moreover, the JMS framework itself is optimized on a self-tuning
WebLogic Server. However, it is possible to see the cost differentials of using various options,
thus setting a level of expectation for the general behavior of JMS. Because you cannot test all
possible combinations, you limit yourself to a subset of options by using a simple messaging
application.
Persisting messages on the server will improve reliability, but at the cost of performance. In
several real-world scenarios, reliability takes precedence.
The WebLogic Server has seen a lot of improvement in the disk write capabilities. This, in
particular, improves JMS persistence by using a file store.
There are three disk write policies available:
Cache Flush
Direct Write
Disabled
This practice explores the cost differentials of using these three policies.
mainserver
Domain: ptcourse
Port: 7003
File Store:
Cache Flush
Direct Write
adminserver
Disabled
MessagingApp
Port: 7001
User credentials
Username
Password
weblogic
Welcome1
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001
Managed Server
mainserver
localhost
7003

Chapter 10 - Page 3
Practice 10-1: Tuning JMS
Type
Name
Target
JMS Server
PTJMSServer
mainserver
JMS Module
PTJMSModule
mainserver
JMS ConnectionFactory
PTConnectionFactory
jms.PTConnectionFactory
JMS Queue
PTQueue
jms.PTQueue
File Store
FileStore_CacheFlush
N/A
File Store
FileStore_DirectWrite N/A
File Store
FileStore_Disabled
N/A
Mean Test Time (ms)
Successful
Tests
Errors
Mean Test Time (ms)
Successful
Tests
Errors
Mean Test Time (ms)
Successful
Tests
Errors
Performance statistics
Metric
MessagingApp
FileStore_CacheFlush
Metric
MessagingApp
FileStore_DirectWrite
Metric
MessagingApp
FileStore_Disabled
1.
b.
2.

setup command:
Start the Administration Server, and mainserver in ptcourse. Then deploy the
MessagingApp application.
a.

$> start_ptadm.sh
$> start_ptmain.sh
b.
Create the necessary JMS resources and deploy the MessagingApp application.

Chapter 10 - Page 4
JMS resources
cd exercise/WLSTScripts
./createStores.sh
java weblogic.WLST create_jms_resources.py
java weblogic.WLST deploy.py
java weblogic.WLST createFileStore.py
c.
3.
4.
Verify and test the application by opening a Web browser and navigating to
http://localhost:7003/ message-producer.
Change the persistent store type to FileStore_CacheFlush.
a. Open a Web browser and navigate to http://localhost:7001/console/. Log in as
weblogic/Welcome1.
b. In the Change Center, click Lock & Edit to initiate configuration changes.
c. In Domain Structure, navigate to ptcourse > Services > Messaging > JMS Servers.
d. Click PTJMSServer. PTJMSServer was configured in the ptcourse domain.
e. On the General tab, change the persistent store to FileStore_CacheFlush.
f. Click Save. Then click Activate Changes in the Change Center.
Restart the mainserver for the changes to take effect.
a.
Stop the mainserver by using the following script. You may need to enter the
username (weblogic) and password (Welcome1) in the ensuing windows.
$> stop_ptmain.sh
b.
Start the mainserver again.

$> start_ptmain.sh
5.

b.

c.
finished running all threads, the JMS_Test_Logs folder containing the files of the stress
d.
3) Errors (if any)
Stop and start mainserver.
e.
$> stop_ptmain.sh
$> start_ptmain.sh
6.
7.
Change the persistent store type to FileStore_DirectWrite.

a. Repeat step 4, this time changing the persistent store type to FileStore_DirectWrite.
Run the stress test again using The Grinder.

Chapter 10 - Page 5
$>
$>
$>
$>
$>
8.
9.
Repeat step 5 and record the new results in the Performance statistics table
(Persistent store: FileStore_DirectWrite).
Change the persistent store type to FileStore_Disabled.
a. Repeat step 4, this time changing the persistent store type to FileStore_Disabled.
Run the stress test again using The Grinder.
a. Repeat step 5 and record the new results in the Performance statistics table
(Persistent store: FileStore_Disabled).

Chapter 10 - Page 6
a.
Chapter 11
Chapter 11 - Page 1
Practices Overview
are using.

Chapter 11 - Page 2
In this practice, you compare the performance between in-memory and file replication
strategies.
Overview
A WebLogic Server cluster consists of multiple WebLogic Server instances running
simultaneously and working together to provide increased scalability and reliability. With many
servers in the cluster, client sessions (HttpSession) need to be replicated so that server
failure does not result in loss of data. But this degrades performance due to the overhead of
replication (persistence).
The WebLogic Server provides three ways of replicating sessions:
JDBC
File
In-memory
In this practice, you focus on file replication and in-memory replication strategies.
Specifications
The domain configuration for this practice:
Domain: ptcourse
Cluster: storecluster
UDP Address: 239.192.0.0: 7001
adminserver
ShoppingCartApp
Port: 7001
File directory:
serverA
/tmp/WLSTemp
Port: 7005
serverB
Port: 7007
ProxyApp
serverC
proxyserver
Port: 7009
Port: 7011
User credentials
Username
Password
weblogic
Welcome1
Type
Name
Address
Port
Admin Server
adminserver
localhost
7001

Chapter 11 - Page 3
Practice 11-1: Tuning Session Persistence
storecluster
239.192.0.0 7001
Managed Servers serverA

in cluster
serverB
localhost
7005
localhost
7007
serverC
localhost
7009
proxyserver
localhost
7011
Managed Server
Performance statistics: File persistent store

Metric
ShoppingCartApp
Performance statistics: In-memory persistent store
Metric
InsuranceApp
1.
b.
2.

setup command:
Start the Administration Server. Set up the managed servers ServerA, ServerB,
ServerC, and proxyserver. Then create the cluster and deploy the ShoppingCartApp
application to the cluster and proxyApp to proxyserver.
a.
In the gnome-terminal, navigate to the /lab11_01/exercise/WLSTScripts

folder.
$ cd ~/wls11g_tune/labs/lab11_01/exercise/WLSTScripts
b.
Start the administration server.

$> start_ptadm.sh
c.
Create managed servers by using the create_server.py WLST script.

$> java weblogic.WLST create_server.py
d.
Configure the cluster by using the cluster_creation.py WLST script.

$> java weblogic.WLST cluster_creation.py
e.
To enable easy startup of all the managed servers, copy boot.properties from the
Administration Server configuration location to individual managed servers. You can
run the copy_boot.sh shell script.
$> ./copy_boot.sh

Chapter 11 - Page 4
Cluster
Start the managed servers: proxyserver, ServerA, ServerB, and ServerC. You
can use the start_clust.sh script.
$> ./start_clust.sh
g.
Ensure that the servers are running, and then deploy the ShoppingCartApp and
proxyApp applications by using the deploy.py WLST script.
h.
3.
Log out of the Administration Console, and using the same browser window, verify and
test the application by navigating to
http://localhost:7011/ShoppingCartApp/.
Verify that the persistent store type is file.
a. Navigate to the lab11_01/exercise/applications/ShoppingCartApp/WEBINF subdirectory.

b.
Open the weblogic.xml deployment descriptor with a text editor.
c.
Verify that the persistent store type is file and that the temporary directory is
/tmp/WLSTemp.
<?xml version='1.0' encoding='UTF-8'?><weblogic-web-app
...
<session-descriptor>
<persistent-store-type> file </persistent-store-type>
<persistent-store-dir>
/tmp/WLSTemp
</persistent-store-dir>
</session-descriptor>
</weblogic-web-app>
4.

a. In the gnome-terminal, navigate to the lab11_01/grinder subfolder and set up the
environment variables for The Grinder.
b.
Run the stress test using the following command:

c.
finished running all threads, the Cluster_Test folder containing the files of the stress
d.
5.
3) Errors (if any)
Change the persistent store type from file to memory.
a. Navigate to the following folder:

lab11_01/exercise/applications/ShoppingCartApp/WEB-INF.

Chapter 11 - Page 5
f.
Open the weblogic.xml deployment descriptor with a text editor.
c.
Change the persistent store type from file to replicated as shown. Save and
close the file.
<?xml version='1.0' encoding='UTF-8'?><weblogic-web-app
...
<session-descriptor>
<persistent-store-type>
replicated
</persistent-store-type>
</session-descriptor>
</weblogic-web-app>
d. Start adminserver using start_ptadm.sh.

e.
6.
Using the Administration Console, update the ShoppingCartApp application. Verify

that the application is targeted to all the servers in the cluster.
f. Open a Web browser and navigate to
http://localhost:7011/ShoppingCartApp/. Browse to make sure that the
application is running.
Run the stress test again by using The Grinder.
a. Repeat step 4 and record the new results in the Performance statistics: in-memory
persistent store table.
c. Stop the managed servers.
Note: You can also use the System Monitor tool to view and kill the Java processes. The
System Monitor can be found under Applications > System > Administration > System
Monitor.
Using Preferences, add arguments to the process fields to associate Java processes with
servers.

Chapter 11 - Page 6
b.

Chapter 11 - Page 7
Then, right-click the process and select Kill Process to terminate the Java process.
Chapter 11 - Page 8
Chapter 12
Chapter 12 - Page 1
Practices Overview
There is no practice for Lesson 12.

Chapter 12 - Page 2

ORacle Tune Improvement

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ORacle Tune Improvement

Hochgeladen von

Copyright:

Verfügbare Formate

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Oracle University and Sentra inversiones y servicios LTDA use only

Oracle WebLogic Server 11g:

Oracle University and Sentra inversiones y servicios LTDA use only

Practices for Lesson 1 .....................................................................................................................................1-1

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle University and Sentra inversiones y servicios LTDA use only

Oracle University and Sentra inversiones y servicios LTDA use only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1

Oracle University and Sentra inversiones y servicios LTDA use only

Practices for Lesson 1

Logging in to your machine

Starting and stopping Oracle 11g Database and its listener

where XX_YY is the current practice number (for example,

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1

Oracle University and Sentra inversiones y servicios LTDA use only

Overview of Practices for Lesson 1

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1

Oracle University and Sentra inversiones y servicios LTDA use only

Practice 1-1: Getting Familiar with the Lab Environment

Now navigate to /u01/app/oracle/Middleware/11.1.1. This folder contains the

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 1

Oracle University and Sentra inversiones y servicios LTDA use only

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

Overview of Practices for Lesson 2

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 2

Start a Grinder agent using The Grinder console

Configure and run a test using The Grinder console

Run the test script and evaluate performance metrics

Navigate to the /home/oracle/wls11g_tune/labs/lab02_01 folder and run the

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

Confirm that the proxy started successfully:

The TCPProxy Console window is also displayed:

Log in as the patient fred@golf.com/weblogic.

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

Click the Profile and then click the Logout button.

View the grinder.properties file in the

Launch another gnome-terminal and run the set_course_env.sh shell script.

Navigate to ~/wls11g_tune/labs/lab02_01/grinder and execute the following:

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

Run the test case and record the performance metrics.

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

(agent): waiting for console signal

Stop the MedRecSvr1 and MedRecAdm servers by using the scripts.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 2

Oracle University and Sentra inversiones y servicios LTDA use only

Oracle University and Sentra inversiones y servicios LTDA use only