22 - Performance Tuning and Stress Testing - Slide

2003 BEA Systems, Inc.
819
Performance Tuning and
Stress Testing
At the end of this module you will be able to:
9 Understand the need for systematic stress testing
9 Use the console to recognize performance
bottlenecks
9 Tune WebLogic Server server parameters
9 Tune WebLogic EJ B parameters
Performance Tuning and Stress Testing-1
Module 22
Performance Tuning and Stress Testing-1
2003 BEA Systems, Inc. 820
Road Map
1. Performance Tuning and Stress Testing
T he Need for Stress T esti ng
When the CPU I s Bound
When the I O I s Bound
T uni ng Vari ous WebLogi c Server Parameters
2. WLS EJ B Tuning Parameters
3. Benchmarking Concepts
4. Web Benchmark and Grinder
Performance Tuning and Stress Testing-2 Performance Tuning and Stress Testing-2
Introduction
fThe performanceof a WebLogic Server system is
rated by its:
response time
latency
throughput
fThe scalabi li ty of a WebLogic Server system is
rated by its ability to add more:
concurrent users
resources
Stress Testing
fStress testing a WLS application requires:
plans that describes what will be tested
ways to simulate live systems
ways to identify performance problems
fStress testing should include:
micro-benchmarks
a test of the entire system
Benchmarks
fA benchmarkis a measurement of the
performance of your system.
fBenchmarks:
must be realistic
should use the database access
have clients connecting over a WAN
should have real people testing the application
fSince all applications run differently, your
application will be your best benchmark.
Changing WLS Properties
fPotential bottlenecks must be isolated to
determine if they are indeed problems.
fSteps for changing properties:
create an appropriate and repeatable test
measure baseline performance
modify a single WebLogic Server property
re-measure performance
CPU Bound
fThe CPU bound situation is easy to spot since the
CPU is running at or near 100%.
fPossible causes include:
garbage collection
the J ava application
fSolutions include:
monitoring the garbage collection
profiling the J ava application
Java Virtual Machine and the Heap
fJ DK 1.3.x and above use code optimization based
on usage statistics (Hot Spot).
fWhen stress testing, run more than one test to
allow the optimizer to gather statistics.
fThe J ava Virtual Machine heap contains:
objects actively being used
non-referenced objects
free, available memory
Memory and Heap Size
fHow much memory is enough?
use 80-85%of available RAM
fUpper and lower limits can be specified.
the minimum represents an amount always dedicated to
this J VM instance
the maximum represents the most that can be taken by
this J VM to instantiate new objects
for best performance set the minimum and maximum
values to be the same
Specify minimum and maximum heap with ms and mx:
10
0101
1110
java ms384m mx384m weblogic.Server
Monitoring JVM Memory
fWith J DK 1.3.x, you can monitor garbage
collection from the command line.
Monitoring JVM Memory
java ms128m mx128m verbosegc weblogic.Server
Syntax of using verbosegc:
10
0101
1110
Determining Heap Size
fTurn on verbose garbage collection output and
redirect stderr & stdout to log file.
fAnalyze:
how often is GC taking place?
how long is GC taking? (major GC should be shorter
than 3~5 seconds)
what is average memory footprint?
fMay want to set generation sizes.
fMake sure the heap size is not larger than the
available free RAM on system.
Detecting Low Memory Conditions
fWebLogic Server detects low memory by sampling
the available free memory a set number of times
during a time interval.
I/O Bound
fThe I/O bound case has the following properties:
the CPU is not saturated
performance is the same regardless of client load (no
matter how many clients there you always have 50 TPS
to the database)
fTypes of I/O bound:
database bound
network bound
Database Bound
fThe bottleneck for your application is found to be
your database.
fConfiguration solutions:
use indexing
allow more database connections
use a fast, dedicated machine
fine-tune your database (see vendor documentation)
Optimizing the Connection Pool
fMore connections in a connection pool may boost
performance.
fDont use more connections than the number of
execute threads.
fIdeally, new connections never have to be created
while the application is running.
Configuring a Prepared Statement
Cache for a JDBC Connection Pool
fWLS stores prepared statements used in
applications and EJ Bs until it reaches the number
of prepared statements that you specify as the
prepared statement cache size in the J DBC Pool.
fWhen an application or EJ B calls any of the
prepared statements stored in the cache,
WebLogic Server reuses the statement stored in
the cache.
Network Bound
fThe network can be your bottleneck if it gets
saturated.
fMonitor the network to determine how much
bandwidth is being used.
fNetworks can saturate with as low as 50%
bandwidth use.
fPossible solutions:
buy more bandwidth
larger packets make better use of the network
bandwidth
OS-specific configuration
fThe Performance Monitor is a Windows utility to
monitor system characteristics
fThe Performance Monitor displays statistics for:
processors
memory
file handles
threads
processes
network activity
Using the Windows Performance
Monitor
Monitoring Network Activities
Under Windows
1 1
2 2
3 3
4 4
5 5
Tuning Windows TCP Parameters
f The Windows TcpTimedWaitDelay parameter can
impact network performance.
Registry location:
HKLM\System\
CurrentControlSet\
Services\Tcpip\Parameters
Value Name:
TcpTimedWaitDelay
Value Type: REG_DWORD
Time in seconds
Valid Range: 30-300
(decimal)
Default: 240 (decimal)
Recommended value: 60
(decimal)
Registry location:
HKLM\System\
CurrentControlSet\
Services\Tcpip\Parameters
Value Name:
TcpTimedWaitDelay
Value Type: REG_DWORD
Time in seconds
Valid Range: 30-300
(decimal)
Default: 240 (decimal)
Recommended value: 60
(decimal)
Some UNIX Monitoring Tools
fUNIX provides many tools for monitoring system
performance, such as:
sar: system activity (Solaris)
mpstat: per-processor statistics (Solaris)
vmstat: virtual memory statistics
netstat: network statistics
iostat: I/O statistics
Tuning Solaris TCP Parameters
fThe following parameters can impact network
performance:
tcp_time_wait_interval
tcp_conn_req_max_q
tcp_conn_req_max_q0
Default values and commonly used values:
tcp_time_wait_interval : default 240000 ms (240 sec)
recommended 60000 ms (60 sec)
tcp_conn_req_max_q : default 128
recommended >= 128
tcp_conn_req_max_q0 : default 1024
10
0101
1110
Threads & Performance
fWLS does all processing in thread pools.
fThreads are allocated as:
reader threads for handing network traffic
execute threads for processing user requests
Execute Thread
Pool
Reader Thread
Pool
Incoming Requests
Execute Queue
9 9 9 9 9 9
1
1
1
Managing Threads
fThe thread count should be increased when WLS
is rejecting requests and the CPU is not running at
100%.
fThis happens when calls to a database or network
resource blocks.
Blocked Execute
Threads
Full Execute Queue
Server Waits and So Do Clients
9 9 9 9 9 9 9 9 9
1
1
1
Socket Reader Threads
fCluster performance is highly dependent on
socket reader threads.
fTwo factors determine socket communication
efficiency:
type of socket reader implementation
if J ava socket readers are used, server must be
configured with enough socket reader threads
fTwo types of socket readers are:
nativeprovide best performance
pure J avaforced to use inefficient socket polling
Configuring Reader Threads
5 5
2 2
4 4
3 3
1 1
Configuring Execute Threads
3 3
2 2
1 1
Configuring Execute Threads
5 5
4 4
fTypical values for the Thread Count are between
15-100 threads.
Built-in Execute Queues
fBy default, WLS is configured with
a default execute queue (default) that contains 15
threads,
2 reserved queues for communicating with the WLS
Admin Console (__weblogic_admin_html_queue that
contains 2 threads and __weblogic_admin_rmi_queue
that contains 10 threads)
Thread Usage Control Through Multiple
Execute Queues
fAn execute queue represents a named collection
of execute threads that are available to one or
more designated servlets, J SPs, EJ Bs, or RMI
objects.
fPossible reasons to configure additional queues
include:
optimize the performance of critical applications
throttle the performance of nonessential applications
remedy deadlocks in thread usage
Assigning Servlets, JSPs,
EJB Objects to Execute Queues
fFor servlets and J SPs, in the web.xml file, specify
as an initialization parameter the queue name as
the value of the wl-dispatch-policy
parameter
fFor RMI objects, use the -dispatchPolicyoption in
the weblogic.rmic compiler.
fFor EJ B objects, use the -dispatchPolicyoption
with weblogic.ejbc. weblogic.ejbc passes this
option and its argument to weblogic.rmic when
compiling the EJ B.
Tuning Execute Queues for
Overflow Conditions
fTo detect and address overflow conditions in a
queue, configure:
the threshold at which the server indicates an overflow
condition. This value is set as a percentage of the
configured size of the execute queue (theQueueLength
value).
the number of threads to be added to the queue when
overflow is detected.
the min and max number of threads available to the
queue.
Detecting Stuck Threads
fWLS diagnoses threads as stuck if it is continually
working (not idle) for a set period of time.
fIf all threads in default queue become stuck, server
changes its health state to "critical".
fA server changes its health state to "warning" if the
following execute queues become stuck:
__weblogic_admin_html_queue
__weblogic_admin_rmi_queue
user-defined execute queue
Tuning Connection Backlog Buffering
fTheAcceptBacklog attribute specifies how many
TCP connections can be buffered in a wait queue.
Transactions and Performance
fA typical transaction commits or rolls back within
1-2 seconds.
fThe default transaction timeout is 30 seconds.
fSuggestions on using transactions include:
keep the transactions short to help performance
only use transactions when they are necessary
Configuring Transactions
Section Review
9 The need for stress testing
9 Various bottleneck conditions
9 Tuning WebLogic Server parameters
In this section we discussed:
Road Map
EJB Pooling & Caching in WLS
fA free-pool stores identical EJ B instances for EJ B
types stateless, entity and message-driven beans.
fA cache stores unique and identifiable EJ B
instances in memory to improve performance for
EJ B types stateful and entity beans.
fPooling and caching are (mostly) set up by editing
the file META-INF\weblogic-ejb-jar.xml.
Configuring Stateless Session EJB Pool
fYou can manage the stateless session EJ B pool by:
capping the number of instances
setting an initial pool size
Snippet from META-INF\weblogic-ejb-jar.xml:
<!- Other Tags As Appropriate Here -->
<weblogic-enterprise-bean>
<ejb-name>HelloEJB</ejb-name>
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-free-pool>
<initial-beans-in-free-pool>5</initial-beans-in-free-pool>
</pool>
</stateless-session-descriptor>
<jndi-name>HelloWorld</jndi-name>
</weblogic-enterprise-bean>
10
0101
1110
Configuring Stateful Session EJB Cache
fYou can manage the stateful session EJ B cache by:
capping the number of instances
setting a idle-timeout period
setting the passivation strategy for the cached EJ Bs
Snippet from META-INF\weblogic-ejb-jar.xml:
<!- Other Tags As Appropriate Here -->
<ejb-name>HelloEJB</ejb-name>
<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>60</idle-timeout-seconds>
<cache-type>NRU</cache-type>
</stateful-session-cache>
</stateful-session-descriptor>
<jndi-name>HelloEJB</jndi-name>
</weblogic-enterprise-bean>
10
0101
1110
Configuring Entity EJB Pool & Cache
fYou can manage the entity EJ B:
pool by capping the number of instances and setting an
initial pool size
cache by capping the number of instances and setting a
timeout period
META-INF\weblogic-ejb-jar.xml Snippet:
<ejb-name>DogEBean</ejb-name>
<entity-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-free-pool>
<initial-beans-in-free-pool>5</initial-beans-in-free-pool>
</pool>
<entity-cache>
<max-beans-in-cache>100</max-beans-in-cache>
<idle-timeout-seconds>30</idle-timeout-seconds>
</entity-cache>
</entity-descriptor>
10
0101
1110
Determining Pool Size
fFactors to consider to determine how many EJ Bs
should be in the pool include:
number of threads set in WLS
number of concurrent clients
number of dependent backend resources (for example,
database connections)
fPool size will equally affect all servers of a cluster.
Determining Cache Size
fSome criteria that affect the size of your cache
include:
the total amount of J ava heap space available in the VM
the number of different stateful session and entity beans
deployed
the amount of memory a single EJ B consumes while
active
the number of concurrent clients
clustering requires more memory because of replication
of EJ Bs
ejbLoad() and ejbStore()
Behavior for Entity EJBs
fBy default, WLS calls ejbLoad() and
ejbStore():
a transaction is initiated for the entity EJ B. The client
may explicitly initiate a new transaction and invoke the
bean, or WLS may initiate a new transaction in
accordance with the bean's method transaction
attributes
WLS calls ejbLoad() to read most current version of
bean's persistent data from datastore
when the transaction commits, WLS calls ejbStore()
to write persistent fields back to datastore
Entity EJB Concurrency Strategies...
fExclusive concurrency strategy:
places an exclusive lock on cached entity EJ B instances
when the bean is associated with a transaction
blocks other requests for the EJ B instance until the
transaction completes
was the default for WLS 3.1 through 5.1
Entity EJB Concurrency Strategies...
fDatabase concurrency strategy:
defers locking requests for an entity EJ B to the
underlying datastore
allocates a separate entity bean instance and allows
locking and caching to be handled by the database
is the default option
Entity EJB Concurrency Strategies
fIn optimistic concurrency:
locks are not held in the EJ B container or database
during a transaction
the EJ B container verifies that none of the data updated
by the transaction has changed before committing the
transaction
the EJ B container rolls back the transaction if any
updated data changed
Entity EJB Concurrency Strategies
fReadOnly concurrency strategy:
is used only for read-only entity beans
activates a new instance for each transaction so that
requests proceed in parallel
configure WLS to check read-only entity beans with
read-timeout configured whether cached data is older
invalidates read-only beans when invalidate() is called
and sends multicast message through cluster to
invalidate cached copies
Combined Caching with Entity EJBs
fCombined caching allows multiple entity beans
that are part of the same J 2EE application to share
a single run-time cache.
fSpecify an application-level cache in weblogic-
application.xml.
fSpecify an entity-descriptor in weblogic-ejb-
jar.xml to use the application-level cache.
Caching Entity Beans
Between Transactions
f Caching Entity Beans between transactions is:
allowed only if the concurrency strategy is Exclusive, ReadOnly or
Optimistic
disabled with Exclusive Concurrency
f In Optimistic concurrency strategy EJ B container:
reuses the cached values from previous transactions.
ensures that the updates aretransactionallyconsistent by checking
for optimistic conflicts at the end of the transaction
broadcast notifications for updates of optimistic data to other
cluster members to help avoid optimistic conflicts
f EJ B Container always performs long-term caching of read-
only data.
Section Review
9 WebLlogic Server specific EJ B tuning parameters
Road Map
Understand Why to Benchmark Appli cati ons
Descri be What and When to Benchmark
Descri be Benchmark Results
Why to Benchmark
fBenchmarks:
allow you to determine if performance requirements are
being met
can be used to determine that a use case is performing
poorly
can determine if tuning the application, operating
system, or WLS increased or decreased performance
What to Benchmark
fBenchmarks should be performed on:
functional areas of the application
the full application
fBenchmarks can be used to record:
timing measurements
hardware measurements
resource consumption
timing measurements under varying loads
When to Benchmark
fBenchmarks should be performed on:
functional areas once they are written
the whole application once it is finished
fBenchmark the application after any change to the
application, an operating system parameter, or a
WLS parameter.
How to Benchmark
fPerform a benchmark with a commercial or freely
available tool, such as the:
Web Benchmark (BEA)
Grinder
SPECjbb2000
ECPerf
WebBench
many others
fAlternatively, you can write your own
measurement code to perform benchmarks.
Section Review
9 Why to perform benchmarks within a development
project
9 What to perform benchmarks on
9 When to benchmark
9 Reporting benchmark
results
Road Map
Descri be the Web Benchmark
Confi gure the Web Benchmark
Descri be a Benchmark Example T hat Uses the Web
Benchmark
Gri nder
Introduction to the Web Benchmark
fThe Web Benchmark:
is an Alpha BEA product, suitable for si mpletesting
is a J ava program that is executed from the command-
line
can be used to stress test HTTP servers
allows administrators to hit pages on a particular site
with multiple clients/threads
fThe time each client/thread takes to complete is
reported to the output.
Configuring the Web Benchmark
Follow these steps to configure the Web Benchmark:
1. Download Web Benchmark.
The Web Benchmark, distributed in a zip file bench.zip, can be retrieved:
From BEAsdeveloper site:
http://developer.bea.com/ftp_bin/bench.zip
In the students folder:
%STUDENT%\lab28\benchmarkKit\bench.zip
2. Unzipbench.zip to a directory.
Create a new directory and unzip the contents of bench.zip to
this directory.
3. Update the system CLASSPATH.
Add the newly created directory to your system's CLASSPATH.
Executing the Web Benchmark
java BenchClient <#_of_threads> <host> <port> "<URI>" <iter>
General Syntax:
#_of_threads := The number of clients
host := The servers DNS name or IP address
port := The port the server is listening on
URI := The virtual mapping, extra path information, and query string
iter := The number of requests each client will send
Examples:
java BenchClient 15 192.168.1.100 7001 "/index.jsp" 45
java BenchClient 20 localhost 4001 "/getItem.jsp?id=4" 5
10
0101
1110
Example: The Application
Promote an Employee
Raise an Employees Salary
Fire an Employee
Hire an Employee
Manager
List all Current Employees
Example: The Application
employeeinfo
getConnection()
getAllEmployees()
updatePosition()
updateSalary()
removeEmployee()
addEmployee()
getNewID()
getAllEmployeeInfo()
HRdatabase
allemployees.jsp
payroll.war
hire.jsp
fire.jsp
raise.jsp
promotion.jsp
welcome.html
Example: The Environment
fThe WebLogic Server parameters are:
version = 7.0
service pack = 1
heap size = 128 MB
number of execute threads = 15
percentage of socket readers = 33
accept backlog = 50
fThe hardware parameters are:
processor speed = 600 MHz Pentium III
amount of RAM = 512 MB
operating system = Windows 2000 version 5
Example: Starting a Test
20 clients each making 15
requests to the URL
http://localhost:7001/payroll/welcome.html
http://localhost:7001/payroll/welcome.html
URL to test:
Web Benchmark command:
10
0101
1110
java BenchClient 20 localhost 7001 "/payroll/welcome.html" 15
Example: The Results
Example: Starting A Test
Note: The URL and the Web Benchmark command are single-
line commands.
URL to test:
http://localhost:7001/payroll/promotion.jsp?employee=9+Ryan
+Lewis&newposition=Senior+Programmer&btnSubmit=Update
+Employee+Information
Web Benchmark command:
10
0101
1110
java BenchClient 10 localhost 7001 "/payroll/promotion.jsp
?employee=9+Ryan+Lewis&newposition=Senior+Programmer
&btnSubmit=Update+Employee+Information" 2
Example: The Results
Grinder
fGrinder:
is load testing software released under the GNU public
license
support a graphical view of benchmark results
uses java plug-ins as clients to test code
provides sample plug-ins for testing HTTP and EJ B
Services
Can be downloaded from http://grinder.sourceforge.net
Grinder Installation
Follow these steps to configure the Grinder:
Step 1: Download Grinder
Grinder is distributed in a J AR file and can be downloaded from
http://grinder.sourceforge.net.
Step 2: Unzip the file to a directory.
Extract the files to a directory.
Step 3:Update the system CLASSPATH.
Add the grinder.jar file to your CLASSPATH. The grinder.jar fileis located
in the lib directory.
Step 4: Setup a test directory.
Step 5: Execute Grinder.
Step 6: Execute Grinders console.
Setting Up a Test Directory for Grinder
fThe test directory:
contains the grinder.properties file
can be located anywhere on your computer
fThe grinder.properties file contains:
Configuration information about tests
Configuration property name/value pairs
Grinder.properties file
Example of a grinder.properties files:
grinder.processes=5
grinder.threads=20
grinder.cycles=15
grinder.receiveConsoleSignals=true
grinder.multicaseAddress=228.1.1.1
grinder.multicastPortel=1234
grinder.reportToConsole=true
grinder.console.multicastPort=1235
grinder.logDirectory=log
grinder.appendLog=False
grinder.plugin=net.grinder.plugin.http.HttpPlugin
grinder.test0.sleepTime=19177
grinder.test0.parameter.url=http://localhost:7001/security
grinder.test1.description=Image
grinder.test1.sleepTime=40
grinder.test1.parameter.url=http://localhost:7001/security/logo.gif
10
0101
1110
<grinder.properties>
This Directory must exist
before starting Grinder
Using the Grinder Console
1 1
2 2
3 3
Summary Statistics
Benchmark Results
fBenchmark results should be reported with details
about:
the application's design
the type of operating system
the version and service pack of WLS
the hardware
performance characteristics of external systems
Benchmark Results
f A metric should be developed which tabulates the benching results:
PendReq
# of
ServReq
# of
CPU
100
100
100
100
100
# of
Itera
tions
Total Time
for
Execution
Heap
Usag
e(kb)
# of
IdleQue
Min
http:\\localhost:7001\estore\control
category
?productList_Dogs_startIndex=5
&productList_Dogs_next_true
&category_id=DOGS&x=58&y=14
http:\\localhost:7001\estore\control\categor
y?category_id=BIRDS
http:\\localhost:7001\estore\control\cart?ac
tion=purchaseItem&itemId=EST-3
http:\\localhost:7001\estore\category?cate
gory_id=DOGS
http:\\localhost:7001\estore\control\main
# of
MEM
# of
Clients
URL
f It may be beneficial to store the benchmark results in a database also.
It would allow administrators to observe long-term trends and establish
reliable baseline data.
Using JMX Programming to Log Data
During Load Testing
fUsing J MX programming for logging purposes
avoids any UI overhead during heavy load testing.
fSome useful runtime Mbeans for performance
monitoring during load testing:
JVMRuntimeMBean,
ExecuteQueueRuntimeMBean,
JTARuntimeMBean, EJBCacheRuntimeMBean,
EJBPoolRuntimeMBean,
EJBTransactionRuntimeMBean,
JDBCConnectionPoolRuntimeMBean,
JMSDestinationRuntimeMBean,
ServletRuntimeMBean,
WebAppComponentRuntimeMBean
Section Review
9 An introduction to the Web Benchmark
9 How to configure the Web Benchmark
9 A benchmark example that used the Web
Benchmark
9 An introduction to Grinder
Module Review
9 The need for stress testing
9 Various bottleneck conditions
9 Tuning WebLogic Server parameters
9 Tuning WebLogic EJ B
parameters
In this module we discussed:

22 - Performance Tuning and Stress Testing - Slide

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

22 - Performance Tuning and Stress Testing - Slide

Caricato da

Copyright:

Formati disponibili

2003 BEA Systems, Inc.

Potrebbero piacerti anche