Introduction to bpel.rs and bpel.sps Diagnostic Dumps in PS6

There are a couple of new BPEL Diagnostic Dumps that haven't been discussed previously and offer some interesting value. These dumps are bpel.rs and bpel.sps. Here I'll describe what they collect and how to use them. Note that these dumps are available starting in SOA Suite 11.1.1.7 (PS6).


As with all diagnostic dumps, these can be executed from WLST and this is probably the most convenient way to do so.

Steps:
  1. Navigate to <MIDDLEWARE_HOME>/oracle_common/common/bin and execute 'wlst.sh' (or .cmd).
  2. Connect to a server that is running SOA Suite with 'connect('user','pwd','t3://host:port')
  3. Execute the listDumps command to view the available SOA dumps, 'listDumps(appName='soa-infra')'. You should see bpel.sps and bpel.rs in the list.



The data collected by these dumps may seem familiar, especially if you've used DMS, but they do offer a unique capability in that you can specify a duration over which the data is collected. This differs from other SOA dumps which provide aggregate data from when the component was deployed or DMS which provides aggregate data from when the server was started. First I'll describe the data they collect.


bpel.sps provides aggregate performance statistics for <strong>SYNCHRONOUS</strong> BPEL processes like min, max and average processing time. By default the results are provided in a table format, organized by composite process.


bpel.rs provides request level statistics (min, max and avg) but it breaks the stats down by steps in the BPEL engine. So if you have a composite with a BPEL process and you collect this dump over some duration when there is load, you'll get an XML type output that lists each step the BPEL engine took to process each request and every step will have associated statistics. There will only be 1 entry per process / step and a 'count' attribute indicating how many times that step was run. Since it's listing every step in the process, this is a convenient way to see the performance of every activity in the process.


The most unique aspect of these dumps is the ability to specify a time range in which to collect the data. This capability is coupled with the BPEL property statsLastN in a mutually exclusive manner that can be confusing so I'll try to explain it.


If statsLastN is configured for the BPEL engine then you cannot use the duration arguments with these dumps. statsLastN is configured in Fusion Middleware Control under BPEL Properties and then 'More Properties' and specifies the number of BPEL instances to keep statistics on for each deployed process. When enabled, these dumps will provide only the statistics for those instances. So if you have statsLastN set to '10', when you run either of these dumps you will see the statistics for the 10 most recent instances.


If statsLastN is disabled then you must provide the duration argument and optionally the buffer size. The command looks like this:

executeDump(name='bpel.sps', appName='soa-infra', outputFile='/home/oracle/tmp/BPEL_SPS.txt', args={'duration':'10', 'buffer':'1000'})

The duration is in seconds and the buffer says how many entries to store.

Once started in this way, the dump will run for 10 seconds and then provide the output. If there was no load then the statistics will be empty and if statsLastN is enabled you will receive an error.


The output of bpel.sps is self explanatory as it's just a simple table but bpel.rs is more complicated so I wanted to offer a sample:


<stats key="TestHarnessProject:L1SyncBPEL:main:receiveInput:105" min="0" max="1" average="0.2" count="30">
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
<stats key="sensor-send-variable-data" min="0" max="0" average="0.0" count="30">
</stats>
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
</stats>
<stats key="TestHarnessProject:L1SyncBPEL:main:replyOutput:387" min="0" max="1" average="0.33" count="30">
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
</stats>
<stats key="TestHarnessProject:L2SyncBPEL:main:If1:Sequence1:L2SyncBPEL_FileBranch_Assign:99" min="0" max="5" average="0.93" count="30">
<stats key="sensor-send-variable-data" min="0" max="0" average="0.0" count="120">
</stats>
<stats key="sensor-send-activity-data" min="0" max="1" average="0.01" count="60">
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
</stats>
<stats key="TestHarnessProject:L2SyncBPEL:main:If1:If1:93" min="0" max="1" average="0.06" count="30">
</stats>
<stats key="TestHarnessProject:L1SyncBPEL:main:If1:elseif:Sequence4:L1SyncBPEL_L2SyncBPELBranch_Embedded:243" min="5001" max="5006" average="5002.46" count="30">
<stats key="sensor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
</stats>
<stats key="TestHarnessProject:L1SyncBPEL:main:If1:elseif:Sequence4:L1SyncBPEL_L2SyncBPELBranch_Assign2:267" min="1" max="2" average="1.06" count="30">
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
<stats key="sensor-send-variable-data" min="0" max="0" average="0.0" count="120">
</stats>
<stats key="sensor-send-activity-data" min="0" max="1" average="0.01" count="60">
</stats>
</stats>
<stats key="TestHarnessProject:L1SyncBPEL:main:L1SyncBPEL_Assign1:106" min="0" max="1" average="0.33" count="30">
<stats key="sensor-send-activity-data" min="0" max="1" average="0.01" count="60">
</stats>
<stats key="sensor-send-variable-data" min="0" max="0" average="0.0" count="30">
</stats>
<stats key="monitor-send-activity-data" min="0" max="0" average="0.0" count="60">
</stats>
</stats>


Here you can see the individual entries for the 'TestHarnessProject' BPEL activities. Every time these activities are run, the stats get updated. If you have a lot of BPEL processes with a lot of activities this output will get very long so it's good to know the names of what you're interested it, whether it's the project or even the specific activities.


As always I encourage you to try this out and have a look at the output. The ability to collect current data in this way is very useful to diagnose sporadic performance issues and see how your applications are performing under various load conditions.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

This is the official blog of the SOA Proactive Support Team. Here we will provide information on our activities, publications, product related information and more. Additionally we look forward to your feedback to improve what we do.

Search

Categories
Archives
« May 2015
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today