Oa Profiling

7/30/2019 Oa Profiling

1/27

Performance Document

Profiling and Tracing OABased Applications

Primary Authors: Muhannad Obeidat, Applications PerformanceGroup

Created: July 2003

Last Updated: January 2006


2/27

DRAFTDRAFTDRAFTDRAFT

Contents

1.0 INTRODUCTION............................................................1

Goals of Document..............................................................1

2.0 TOOLSOF THE TRADE................................................2

JDeveloper...........................................................................2

OptimizeIt............................................................................2

SQL Trace............................................................................2

PL/SQL Profiler...................................................................3LoadRunner.........................................................................3

3.0 PERFORMANCE METRICS............................................4

Memory Consumption .........................................................4

Response Time.....................................................................5

Total Page Size....................................................................5

4.0 CONFIGURINGTHE TOOLS..........................................6

JDeveloper...........................................................................6

OptimizeIt............................................................................9

SQL Trace..........................................................................10PL/SQL Profiler.................................................................11

5.0 USINGTHE TOOLS.....................................................13

JDeveloper.........................................................................13

OptimizeIt..........................................................................18

SQL Trace..........................................................................23

PL/SQL Trace....................................................................24

Total Page Size..................................................................24

Copyright 2003 Oracle Corporation Page ii of 27 Profiling and Tracing OA Based Applications


3/27


1.0 Introduction

More and more product teams are converging to the OA Frameworkbased technology stack. It is therefore essential that developersknow how to measure the performance of their applications atruntime. This task involves looking at both the middle tier anddatabase code required to implement the desired functionality.

To achieve acceptable levels of performance and response times,OA Framework based applications are required to comply with a setof performance metrics to guarantee scalability and pleasantcustomer experience. Response times and memory consumptionare amongst those metrics.

It is the responsibility of the developer to ensure that their codecomplies with those standards and falls within those limits. Thisdocument will help explain how to measure the different metrics. Itcovers both middle tier (Java code) as well as backend (SQL andPL/SQL) code with more emphasis on the middle tier.

Goals of Document

The goals of this document are:

Describe the different metrics and the associated limits.

Explain how to record and interpret memory consumption fora module.

Explain how to record and interpret CPU consumption for a

module.

Explain how to record and interpret SQL traces for a module.

Explain how to record and interpret PL/SQL profiler output fora module.

Explain how to check for memory leaks in a module.

Copyright 2003 Oracle Corporation Page 1 of 27 Profiling and Tracing OA Based Applications


4/27


2.0 Tools of The Trade

This section describes the different tools and utilities to be used forprofiling the application. All of the Java tools support local andremote profiling. The difference between those two modes is theway you startup the application server. Local profiling is when theapplication server is started from within the profiling tool itself. Ifthe application server is started in the standard way with some

modifications to its command line and the profiling tool attaches toit through a certain port, then this is referred to as remote profiling.

JDeveloper

JDeveloper provides three different types of profilers, namely, CPU,memory and event profiler. It also provides a powerful debuggerthat can be used to identify memory leaks.

For profiling, JDeveloper relies on custom APIs that are onlyavailable with OJVM (Oracle Java Virtual Machine) that ships with

JDeveloper and is meant to be used for development, testing andprofiling purposes. OJVM (9.0.3) is currently available on Windowsplatforms, which means that you will only be able to use it for localprofiling of your JDeveloper project. Beta version of OJVM are alsoavailable on Solaris and Linux.

The debugger on the other hand has two interfaces, one that iscustom to Oracle and another that complies with the standard JPDAinterface for debuggers. This means that you can use it for bothlocal and remote debugging on any platform.

OptimizeIt

OptimizeIt supports both memory and CPU profiling. It implementsthe standard JVMPI interface and is currently available on bothWindows and Unix environments.

Quickapache ports running on Solaris have an option to startOptimzieIt to profile your code. It is a good tool to measure exactmemory consumption and quickly identify memory leaks.

SQL Trace

SQL tracing can be enabled from OA based pages by clicking on thediagnostics button. There are four types of traces:

Standard Trace: Records SQL and top-level PL/SQL callsmade in that session including execution counts, CPU andelapsed times.

Trace with Waits: Same as standard trace including waitevents for all calls.



5/27


Trace with Binds: Same as standard trace including bindvariable values passed at runtime.

Trace with Waits and Binds: Combination of all of the aboveoptions.

PL/SQL Profiler

PL/SQL profiler is an execution profiler for PL/SQL code running as astored procedure inside the database. There are two ways to enablethe profiler. One involves some code change to enable and theother is through an event. The output will be all the differenthotspots in the code including invocation counts.

LoadRunner

LoadRunner is a tool used to simulate virtual users running an

application. It can be used to simulate multiple types of protocolsincluding HTTP and Oracle Forms. This tool is available for productteams wishing to do multi user tests. Please contact theperformance team if you need to run a mutli-user test.



6/27


3.0 Performance Metrics

Different types of metrics are recorded for OA based applications.They are measured on a per page based and include:

Memory Consumption

Response Time

Total Page Size

Memory Consumption

Java language automates memory management and shieldsprogrammer from having to worry about allocating and deallocatingobjects. However, this does not alleviate the responsibility of theprogrammer to write code that utilizes the memory efficiently.

Allocations in latest versions of the JVM are optimized. There is adownside to this though. There is a deferred cost with everyallocation in Java, which is the time it takes the Garbage Collector

(GC) to finalize and cleanup those objects and to reclaim theirmemory back to the heap. This is especially important since the JVMis a shared process that multiple products will be using. Any productpage or process that consumes a lot of memory will affect theoverall performance and health of that particular JVM.

There are two types of allocations that any Java program can make:

Temporary: These are objects that are created to process auser request and go out of scope and are garbage collectedimmediately.

Permanent: These are objects that live for the lifetime of theuser transaction or even worse the lifetime of the userssession.

The total memory footprint for a page in OA should not exceed 5MB.This includes both temporary and permanent objects. Thisdocument will describe techniques to measure the footprint anddifferentiate between the two types. Both allocations are importantand should be optimized. Increasing permanent allocations can bean indication of a memory leak.

Tuning memory allocations in code will not only affect memoryfootprint and memory requirements, it will also affect responsetimes and CPU consumption. For one, wherever a program isallocating a lot of memory, it is also doing a lot of work andconsuming CPU resources. Cutting down on those allocations byoptimizing the code will help reduce footprint and response times.

The second point was already mentioned which is the cost of GConce it gets triggered.



7/27


Response Time

Most page requests will end up executing Java code on the middletier machine and SQL and PL/SQL on the back end machine. Thetotal time it takes to render the response on the browser includestime it takes to execute this code plus network traffic overhead. It isessential for performance tuning to know which part of the code isconsuming this time and how much each is contributing to the total

response time.

For the Java code, CPU profiler will help you identify that. It showsthe hotspots in your code and the latency of method calls. Someprofilers show additional information such as full stack trace ofevery method call and invocation counts for the different methods.

For SQL and PL/SQL code, the SQL trace and PL/SQL profiler are veryuseful to pinpoint expensive statements. The PL/SQL profiler adds asignificant overhead to the test.

The total response time for OA based pages should not exceed 5seconds on a LAN connection. This time is measured from the

minute the user clicks on a link or a button until the response isrendered back on their browser. This is applicable to the differentkinds of actions a user can execute such as searches and submits.

Total Page Size

This is a simple though important test for the different pages in yourproduct. This refers to the HTML size of a page. The HTML sizeincludes the data displayed on the page and the tags required todisplay the page on the browser. OA Framework is already utilizinga number of technologies to reduce the amount of data transfer onthe network. This includes eliminating all formatting and whitepaces in the HTML code

The total page size should not exceed 45KB.



8/27


4.0 Configuring the Tools

This section describes configurations and modes of operation for thedifferent tools available. It will discuss briefly how to set up the tooland what options to use to achieve what you need. This is notmeant to be a replacement for tool specific documentation.

JDeveloper

General Features

JDeveloper can be used in two modes, local and remoteprofiling/debugging:

Local Profiling: This can be done in your local JDeveloperenvironment. If you are able to test and run your pages fromwithin JDeveloper IDE than you can run local profiling andlocal debugging for your Java code.

Remote Profiling: Profiling in JDeveloper is only supported

with OJVM which is currently only available on Windowsplatforms. This means that if your Application Server(QuickApache port) is running on a Unix machine, you willnot be able to do remote profiling.

If you have access to a Windows machine running anapplication server, then you can use OJVM to startup theapplication server and you can remote attach to it from theIDE to profile a project.

Remote Debugging: Remote debugging is both supported forOJVM and the standard JVM. If you can modify the commandline for starting up the application server then you can use

remote debugging regardless of platform.



9/27


Figure 1 Project settings in JDeveloper for remote profiling

Figure 2 Project settings in JDeveloper for remote debugging

Common Setup

Open up the project settings window and navigate toConfigurations -> Development -> Debugger. Removeoracle from the list of Tracing Classes and Packages toExclude.

Navigate to Configurations -> Development -> Profiler.Remove oracle from Classes and Packages to Exclude. Addoracle.jdbc to the same list.



10/27


Navigate to Configurations -> Development -> Profiler ->Memory. Check Manual Sampling. Make sure that Includedand Excluded Instances lists are empty.

Navigate to Configurations -> Development -> Runner. Setthe run target you are planning to profile as your defaultrunner. Add the following in the Java Options:-Djbo.debugoutput=silent

Navigate to Configurations -> Development ->Profiler ->Events to select the events you intend to listen to in theevent profiler.

If you are using centrally staged JDeveloper for 5.10K, youneed two additional steps before you can use the profilers.Navigate to Configurations -> Development -> Libraries.Select 1.3.1_02 (OJVM is not yet available in JDK 1.4) fromthe J2SE Version dropdown. Then navigate toConfigurations -> Development -> Runner and verify thatojvm is selected in the Virtual Machine field. For 5.10J orbelow OJVM is the default so you do not need the above twosteps.

Local profiling

To run local profiling for either memory or CPU, you need toclick on the project

From the Run menu, choose the type of profiling that youwant to perform. The menu options will only be enabled ifyou have selected OJVM in the project Runner setting.

Your application will now start in profiling mode. You shouldwarm up the VM by visiting all the different pages that youwill be profiling at least once before you start taking anysnapshots.

Local Debugging

To run local debugging, you need to click on a project or acertain page you plan to debug.

From the debug window you can select to debug the projectif a default run target is set up correctly. Alternatively, youcan debug a specific page by right clicking on the page andselecting Debug from the context menu.

Remote Profiling

Remote profiling only works with OJVM. The following needs to be

done:

Startup the JVM for the application server using the followingcommand line : java -ojvm -XXtimeportNNNN yourMainClass

In the project settings window, navigate to Configurations ->Development -> Profiler and check Remote Profiling.

Click on the project to profile and select the type of profilerfrom the Run menu.



11/27


A window will popup prompting you to enter host name forthe application server and port number specified in theXXtimeportNNNN option.

Remote Debugging

Remote debugging works with both OJVM and standard JVM. Thefollowing steps are needed to enable it:

For OJVM remote debugging, startup the JVM for the

application server using the following command line :

java -ojvm -XXdebugportNNNN yourMainClass

For standard JVM remote debugging, startup the JVM for theapplication sever using the following command line:

java -server -Xdebug-runjdwp:transport=dt_socket,server=y,suspend=n,address=NNNN

In the project settings window, navigate to Configurations ->

Development -> Debugger -> Remote and check RemoteDebugging.

Click on the project to profile and choose Debug from theDebug menu.

A window will popup prompting you to enter host name for theapplication server and port number specified in the XXdebugportNNNN option or address=NNNN option.

OptimizeIt

OptimizeIt can also be used for remote and local profiling, however,since the tool is available for development through QuikApacheport, local profiling will not be discussed here.

Remote Profiling on QuikApache

Please refer to the following URL for full details on enablingOptimizeIt on QuikApache ports.http://ebizsrv.us.oracle.com/tools/quikapache/documentation/qapprod_optim6_usersdoc.html

The steps in brief are:

Enable OptimizeIt for the port.

Attach with the OptmizeIt client by specifying the host namefor the QuikApache server and the port that OptimizeIt islistening on.

Remote Profiling on RapidInstall/QuikClone environments

If you want to use OptimizeIt on a environment created via RapidInstall or QuikClone, make the following changes to jserv.properties:

http://ebizsrv.us.oracle.com/tools/quikapache/documentation/qapprod_optim6_usersdoc.htmlhttp://ebizsrv.us.oracle.com/tools/quikapache/documentation/qapprod_optim6_usersdoc.htmlhttp://ebizsrv.us.oracle.com/tools/quikapache/documentation/qapprod_optim6_usersdoc.htmlhttp://ebizsrv.us.oracle.com/tools/quikapache/documentation/qapprod_optim6_usersdoc.html


12/27


1. Add /local/appldev/dbadmin/OptimizeitSuite60/lib towrapper.env for LD_LIBRARY_PATH setting. For example:

wrapper.env=LD_LIBRARY_PATH=/ds2/oas/visappl/cz/11.5.0/bin:/ds2/oas/visora/iAS/lib:/ds2/oas/visora/8.0.6/lib:/ds2/oas/visappl/iby/11.5.0/bin:/ds2/oas/visappl/pon/11.5.0/bin:/local/appldev/dbadmin/OptimizeitSuite60/lib

2. Add

wrapper.classpath=/local/appldev/dbadmin/OptimizeitSuite60/lib/optit.jar

3. Addwrapper.env=OPTIT_HOME=/local/appldev/dbadmin/OptimizeitSuite60

4. Add wrapper.bin.parameters=-Xrunpri:startAudit=t,port= -DGCOPSIZE=50-Xbootclasspath/a:/local/appldev/dbadmin/OptimizeitSuite60/lib/oibcp.jar

For example:wrapper.bin.parameters=-Xrunpri:startAudit=t,port=1470-DGCOPSIZE=50-Xbootclasspath/a:/local/appldev/dbadmin/OptimizeitSuite60/lib/oibcp.jar

When you start Apache and Jserv with the above settings, the JVM willbe started with OptimizeIt running at port 1470 (which is the default ifyou dont specify it).

To run the OptimizeIt client and attach to the target JVM, log on to oneof the utility servers via Tarantella such as ap602utl, ap603utl etc.

Then, execute the following:

asu optusr

setenv OPTIMIZEIT_HOME/local/appldev/dbadmin/OptimizeitSuite60

$OPTIMIZEIT_HOME/OptimizeIt

SQL Trace

There are multiple ways to enable SQL tracing. The easiest way is

through the OA Framework UI. The steps are explained below:

The steps are:

Set profile FND : Diagnostics to Yes at user level

Login to Self Service as the above user

Click on Diagnostics icon at the top of page



13/27


Select Set Trace Level and click Go

Select the desired trace level and click Save

Write down the trace id number(s).

Perform the activity that you want to trace

Go back to diagnostics page.

Click on Diagnostics icon at the top of page

Select Set Trace Level and click Go

Selecet 'Disable Trace; and click Go.

Write down the trace id number(s) if different.

Exit application

Go to user_dump_dest for your database and collect the raw

trace file(s) suffixed by the trace id number(s) you haverecorded.

To get a complete SQL trace file make sure that:

Database parameter timed_statistics is set to true.

Database parameter max_dump_file_size is set to unlimited.

PL/SQL Profiler

If you generate a SQL trace and notice that the most of the time isspent in PL/SQL processing rather than SQL statement executionthen you may need to use the PL/SQL profiler to find out the hotspotin the code.

Below is an example of a PL/SQL procedure call that is doing a trivialnumber of disk reads and buffer gets, however, overall time spent inthe procedure is very high which suggest the PL/SQL code isexpensive:

arp_auto_accounting . do_autoaccounting ( :v_mode:i_vmode,

:v_account_class , :v_trx_id:i_trx_id ,

:v_line_id:i_line_id ,

:v_line_salesrep_id:i_line_salesrep_id ,:v_request_id:i_request_id ,:v_gl_date ,:v_orig_gl_date , :v_total_trx_amount:i_total_trx_amount ,

:v_passed_ccid:i_passed_ccid , :v_force_acct_set_no ,:v_cust_trx_type_id:i_cust_trx_type_id ,:v_primary_salesrep_id:i_primary_salesrep_id

,:v_inv_item_id:i_inv_item_id,:v_memo_line_id:i_memo_line_id , :v_ccid:i_ccid ,:v_concat_segments:i_concat_segments ,

:v_num_failed_dist_rows:i_num_failed_dist_rows )



14/27


call count cpu elapsed disk query currentrows------- ------ -------- ---------- ---------- ---------- --------------------Parse 1 0.01 0.01 0 0 00Execute 6 2831.58 2856.62 10 16 06Fetch 0 0.00 0.00 0 0 0

0------- ------ -------- ---------- ---------- ---------- --------------------total 7 2831.59 2856.63 10 16 0



15/27


5.0 Using the Tools

This section describes standard procedures to be used when usingthe different profiling and tracing tools.

For OA Framework based pages, every page request is consideredas one complete unit of processing. All the different performancemetrics limits are based on this assumption. This governs the way

you take snapshots of your code when profiling. This is especiallyimportant when taking memory and CPU snapshots of the Java code.

You should control snapshot generation to coincide with pagerequests.

For the SQL trace, a full trace for the whole transaction is acceptablesince a developer who is familiar with the code will be able to tellwhere the SQL was executed.

For PL/SQL profiler output, multiple executions of the instrumentedprocedure will be assigned run ids and can be distinguished easily.

General guidelines to follow are:

Always warm up VM and visit the different pages you intendto profile at least once before you start profiling.

Use optimized classes rather than debug classes from thedifferent technology stacks.

Turn off debugging and logging flags as well as developermode flags.

Record manual snapshots per page request not for acomplete scenario. This will help you see if your pages are

within the different limits as well as produce moremanageable profiler output.

Make sure your application server is pointing to a recentversion of the JVM and the HotSpot compiler is not disabled.

This can be done through the pool monitor servlet.

The following sub sections explain which tool to use for a certaintest and guidelines specific for that tool.

JDeveloper

JDeveloper has three different types of profilers: memory, CPU andevent. For all the different types, remote and local profiling followthe same rules. For more information about JDeveloper, go tohttp://jdeveloper.us.oracle.com/

CPU Profiling:

JDeveloper is ideal for CPU profiling since it does not add a lot ofoverhead to the test case. This should be your first choice for CPUhotspot detection rather than OptimizeIt mainly because of theminimal overhead added.

http://jdeveloper.us.oracle.com/http://jdeveloper.us.oracle.com/


16/27


After visiting the pages once, you should start recording snapshotsper page and looking at the hotspots in the code. The mostimportant metrics reported for every method are time and stacktime. Time refers to time spent in the method itself. Stack timerefers to time in method plus time spent in all methods called fromthis method. This is referred to as exclusive and inclusive timerespectively. Both of these metrics are important to look at. The firstshows if a certain method is complex or has code that is inefficientwhile the other shows the total latency of the call and the time its

caller waits for it to return.

CPU profiler also shows the complete stack trace for all themethods. The full output can be saved for later investigation asHTML output. The only thing that is currently missing in the

JDeveloper profiler is the execution count for a method. This ismainly because JDeveloper is a sampling profiler.

Figure 3 JDeveloper CPU profiler snapshot

Memory Profiling:

JDeveloper memory profiler is also optimized and does not add a lotof overhead to the test case. However, it is missing the back traces



17/27


for method invocations. This is going to be added in JDeveloper9.0.5. To work around this for now, you can change the filter list forthe classes in the profiler settings to see the caller of a certainmethod that caused a lot of allocations.

Since it is already available locally in your project, it is the easiest toset up. It should be used as a primary check for footprint of thedifferent pages. Snapshot should be recorded per page request. Thetotal is readily available at the top of the profiler window and should

always be checked to make sure it is under the limit of 5MB perpage.

The output will show a list of all the different types of objectsallocated, the number of instances and the total size occupied bythem. You can also get one level back trace to see which methodsallocated the object. However, for the back trace to be accurate, itshould be opened before the snapshot is recorded. This can be doneduring the VM warm up cycle.

The two important metrics that pertain to the snapshot are No. Allocand Sz Alloc. They show the number of objects and their total sizefor that particular snapshot. You can save the snapshot for later

investigation. You should save only one snapshot per file since thesize tend to be big.

Back traces are displayed by double clicking on a certain method,however, this should be done before the snapshot is recorded asmentioned above.

Allocations happening in lower levels of the stack such as JDK itself,JDBC, BC4J and so forth are due to calls coming from product teamcode and should still be investigated to see if calls can beeliminated or their number reduced.

Because of the lack of full stack traces, this is only ideal for early

testing of memory footprint. To get more details, OptimizeIt can beused.



18/27


Figure 4 JDeveloper memory profiler snapshot

Event Profiling:

This is unique to JDeveloper since OptimizeIt does not provide thisfeature. Event profiler shows all contention events as well as GCactivity during the lifetime of the test run. This is very helpful fordebugging concurrency and contention issues. It can also listen forBC4J events and user defined events. Please refer to JDeveloper

documentation for details on how to create custom events if youneed to.

Depending on the events you are listening to, the output will show alist of those events if they happen to be triggered at runtime. ForSynchronization events, it will display the contended threadsnames, object reference contended for, as well duration ofcontention.



19/27


Figure 5 JDeveloper event profiler snapshot

Remote/Local Debugging:

This can be used to debug your code and set breakpoints. It canalso be used to inspect the heap at runtime and see where certainobjects are being referenced. It supports explicit invocation of thegarbage collector, which can be used to detect if certain objects arebeing collected properly or they remain alive because some piece ofcode is keeping a reference to them.

These are the steps to do that:

Startup your application in debug mode and setup anappropriate breakpoint.

From the View menu, select Debug Windows, select Heap.

When the application reaches the breakpoint, in the heapwindow, right click on the heap window and select Add ClassFolder.

Enter the class name your investigating, such asoracle.jbo.ViewRowStorage.

This will display the number of live instances. Force theGarbage Collector by clicking on its icon on the toolbar andobserve if the number of instances goes down or not.



20/27


If a class instance does not get GCed when you expect to,then right click on the instance and choose Show ReferencePaths.

The output is a list of all live references to this object.

Figure 6 JDeveloper Heap window showing reference path for live object

OptimizeIt

OptimizeIt has two different types of profilers: memory and CPU. Forall the different types, remote and local profiling follow the samerules.

CPU Profiling:

OptimzeIt has two different modes of CPU profiler. One is similar toJDeveloper, which is a sampling profiler. The other mode isinstrumentation where every method entry and exist is captured.

The advantage of the instrumentation profiler is that it displays the

invocation counts. This can be very useful in determining problemsin the code were a method is called an excessive number of times.OptimizeIt CPU profiler in instrumentation mode adds a lot ofoverhead compared to JDeveloper. It changes the test case you aretrying to profile. If you are not trying to get invocation counts, youshould use the sampling mode or use JDeveloper CPU profilerinstead. When you are doing CPU profiling, you should disablememory profiling to reduce overhead. There is a link you can clickon the CPU profiler page to disable memory profiling.



21/27


OptimizeIt allows you to control the time the CPU snapshot is taken.This should be done on a per page basis. The output is a list ofmethods and the time spent in every method along with the fullstack trace of the method. The output can be saved for laterinvestigation.

If you check the Only record CPU usage box in the inspectorwindow (which you can open by clicking the i icon) , thenOptimizeIt will report only the CPU usage of the method, and will not

include time spent waiting. For example, if your thread sleeps for 3seconds during execution and also executes some SQL statements,with the CPU usage option checked, the profiler will not include the3 seconds sleep time when in the time reported. Similarly, timespent executing SQL will not be reported. If you do not check thatoption, then the time will include the sleep time (as well as SQLexecution time). If you change that option, you need to stop andstart the CPU profiler again (by clicking the tape icon).

The CPU profiler output window has two panes. The top panedisplays the call tree. You can choose to display from top-down orbottom-up by clicking the right-most button (the button with thewhite and blue triangles). The thread stack entries that are

displayed with a red clock icon are the hotspots. These hotspots arelisted in the bottom pane as well.



22/27


Figure 7 OptimizeIt CPU snapshot showing method invocation counts

Memory Profiling:

Memory profiling in OptimizeIt provides full back traces for all thedifferent objects allocated. It allows you to record memoryallocation per page, however, unlike JDeveloper you can only viewone snapshot at any point of time. It does not display the total sizeof all objects allocated, so you have to sum that up either manuallyor in Excel.

To record a snapshot in OptmizeIt, click on the Mark currentinstance count icon on the toolbar. Run the page and inspect theoutput. The two columns to look at are Diff. and size Diff. These twocolumns display the data for the current snapshot. Double clickingon any object type will display full back traces for those objects. Theback trace window displays percentages based on instance countsrather than instance size. This is important to keep in mind since

JDeveloper memory profiler gives you the ability to sort on either ofthese metrics.

The OptimizeIt memory profiler is ideal for memory leak detection.You can do that using the following steps:

Warm up your VM by running the test case once and loggingout then attach to it from the OptimizeIt client.

Click on Mark the current instance count icon on thetoolbar.

Run your test case and logout.

Invoke GC multiple times from the toolbar icon and see howmany object instances are still alive. These are potentialmemory leaks that should be investigated.

Click on Reference Graph toolbar icon to see live referenceto those objects.



23/27


Figure 8 OptimizeIt memory profiler snapshot

In Optimizeit 6.0, there is a new memory leak detector tool. It

allows you to take snapshots of the heap and select two or moresnapshots to analyze the differences. When you take a heapsnapshot, several full GCs will be done automatically. When themiddle heap snapshot is complete, the middle pane displays theobjects that created and still referenced between the two heapstates and you can sort by the number of outgoing references. Youcan sometimes find the source of memory leaks by focusing onobjects that have new outgoing references. You can select anobject in the middle pane and the bottom pane displays thereference graph for that object.

Please see the Optimizeit help for more details about the memoryleak detector.



24/27


Figure 9 Optimizeit Memory Leak Detector

Quality Analyzer

Optimizeit 6.0 provides a Quality Analyzer feature that will report potential qualityissues such as exceptions thrown, inefficient StringBuffer usage etc. You can clickthe info icon to configure what gets reported. You should look into code that isthrowing a lot of exceptions.



25/27


Figure 10 Optimizeit Quality Analyzer

SQL Trace

SQL trace file will show all the different SQL statements and PL/SQLcalls issued over the JDBC connection. You should use 9i version oftkprof to interpret the file since it reports the wait events if theywere captured in the raw trace file.

The tkprof output file displays a lot of useful information such asCPU and elapsed times, invocation counts, buffer gets and diskreads. It will show runtime execution plans. You can also getexecution plans by specifying an option to tkprof.

Please refer to the following documents for details about readingand analyzing the SQL trace:

http://www-apps.us.oracle.com:1100/performance/sqlrep/SQL_Repository.htm

http://www-apps.us.oracle.com/performance/presentations/scalesql.ppt

http://www-apps.us.oracle.com:1100/performance/sqlrep/SQL_Repository.htmhttp://www-apps.us.oracle.com:1100/performance/sqlrep/SQL_Repository.htmhttp://www-apps.us.oracle.com/performance/presentations/scalesql.ppthttp://www-apps.us.oracle.com/performance/presentations/scalesql.ppthttp://www-apps.us.oracle.com/performance/presentations/scalesql.ppthttp://www-apps.us.oracle.com:1100/performance/sqlrep/SQL_Repository.htmhttp://www-apps.us.oracle.com:1100/performance/sqlrep/SQL_Repository.htmhttp://www-apps.us.oracle.com/performance/presentations/scalesql.ppthttp://www-apps.us.oracle.com/performance/presentations/scalesql.ppt


26/27


PL/SQL Trace

PL/SQL profiler will insert the raw profiling data in plsql_profilertables when the instrumented code is executed. The output showsinvocation counts and CPU time for the different pieces of codeinvoked in a particular procedure. You should use plsql_profilerscripts under ORACLE_HOME to generate the final report.

To enable the PL/SQL profiler , you need to make code changes byinstrumenting the procedure to start and stop the PL/SQL profiler.The steps to enable this are:

Make sure dbms_profiler is installed on the database, if not,please refer to RDBMS documentation on how to install it.

Instrument the procedure you are interested to profile byadding calls to dbms_profiler.start_profiler anddbms_profiler.stop_profiler for the code segment you tend toprofile.

Run the test case.

Generate the PL/SQL profiler report.

Alternatively you can enable the PL/SQL profiler through settingevent 10941. This can be done as follows:

Find out the sid and serial# for the connection you plan toenable profiling for.

From SQL*PLUS, execute:

exec dbms_system.set_ev(sid, serial#, 10941 , 1, );

To write profiler raw data to database tables and turn off,from SQL*PLUS execute:

exec dbms_system.set_ev(sid, serial#, 10941 , 8, off);

Please refer to the following presentation for details aboutgenerating the output and interpreting it.

http://www-apps.us.oracle.com/performance/presentations/optplsql.ppt

Total Page Size

The easiest way to measure page size is to right click on the page inInternet Explorer, select Properties and look at the size field. The

http://www-apps.us.oracle.com/performance/presentations/optplsql.ppthttp://www-apps.us.oracle.com/performance/presentations/optplsql.ppthttp://www-apps.us.oracle.com/performance/presentations/optplsql.ppthttp://www-apps.us.oracle.com/performance/presentations/optplsql.ppt


27/27


number reported is for the raw html code including the data. It doesnot take into account image sizes. It is also important to count thenumber of images and java script file references in your page.

Figure 11 Screen shot of Properties window in Internet Explorer

Oa Profiling

Documents

Transcript of Oa Profiling