Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle B2B
11g Release 1 (11.1.1)

Part Number E10229-04
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

A Performance Tuning and Large Payloads

This appendix contains the following topics:

A.1 Settings for Performance Tuning

To improve performance, set memory arguments appropriately based on your requirements and system. Code clean-up, multithreading, and table indexing are major contributors to maximizing the use of available resources. Java performance tuning also helps in sharing the resources among the various processes based on the usage and need.

When using the large payload settings, the internal delivery channel must be the default channel or a JMS queue.

Changes to B2B configuration properties typically require a server restart. See the following for more information:

The syntax in various examples in this section reflect generic UNIX format.

The following settings improved Oracle B2B performance based on 2 GB of RAM on a 32-bit computer and 200 MB of B2B configuration data. When working in a Windows operating system with large payloads, a 64-bit server is recommended.

A.1.1 Memory Arguments

Memory arguments are captured in DOMAIN_HOME/bin/setSOADomainEnv.sh. Memory tuning applies to Oracle JRocket or SUN JVM, as shown in Example A-1 and Example A-2.

Example A-1 Settings for Oracle JRocket

export JAVA_VENDOR Oracle 
DEFAULT_MEM_ARGS="-Xms1024m -Xmx1024m"

Example A-2 Settings for Sun JVM

export JAVA_VENDOR Sun
DEFAULT_MEM_ARGS="-Xms1024m -Xmx1024m"
if["$JAVA_VENDOR"!= "Oracle"];then
 DEFAULT_MEM_ARGS="$DEFAULT_MEM_ARGS -XX:CompileThreshold=100000 -XX:PermSize=256m -XX:MaxPermSize=256m"

-Xms and -Xmx can be increased up to 2 GB based on memory availability.

A.1.2 Heap Size Settings

Verify the heap size settings in the setSOADomain.sh script (see DEFAULT_MEM_ARGS) before starting any of the following servers in the WebLogic domain:

  • The SOA managed server

  • The WebLogic Admin Server

Using precise heap settings when starting the servers is necessary for B2B to process large payloads.

A.1.3 MDS Cache Size

To set the Metadata Service (MDS) instance cache size, use Oracle Enterprise Manager Fusion Middleware Control to set b2b.mdsCache to a value such as 200000. See Appendix B, "Properties To Set in Fusion Middleware Control," for more information.

A.1.4 Number of Threads

Changing the value of b2b.inboundThreadCount and b2b.outboundThreadCount can improve Oracle B2B message processing. The recommended value depends on your system. For a 2 GB computer, a setting of 3 to 5 is recommended. The b2b.inboundThreadSleepTime and b2b.inboundThreadSleepTime properties put a thread to sleep after message processing. A setting between 10 and 1000 (milliseconds) is recommended.

A.1.5 Stuck Thread Max Time

Changing the value of Stuck Thread Max Time can improve Oracle B2B message processing if a thread is stuck. This is the maximum amount of time that the server checks the number of seconds that a thread must be continually working before the server considers the thread stuck.

Only if you see a stuck thread exception should you change the Stuck Thread Max Time setting in Oracle WebLogic Server Administration Console. Increasing this number can degrade performance.

Navigate to Environment > Servers > soa_server_name > Configuration > Tuning. Set Stuck Thread Max Time, shown in Figure A-1, to a maximum of 1200. (The default value is 600 seconds.)

Figure A-1 Changing Stuck Thread Max Time

Description of Figure A-1 follows
Description of "Figure A-1 Changing Stuck Thread Max Time"

A.1.6 Tablespace Size

If you store more than an a 150 MG configuration, extend or add a data file to increase tablespace size, as shown in Example A-3.

Example A-3 Increasing Tablespace Size

ALTER TABLESPACE sh_mds add DATAFILE 'sh_mds01.DBF' SIZE 100M autoextend on next 10M maxsize unlimited;
ALTER TABLESPACE sh_ias_temp add TEMPFILE 'sh_ias_temp01.DBF' SIZE 100M autoextend on next 10M maxsize unlimited;

A.1.7 JTA Settings

On slower Windows computers (2 to 4 GB, 32-bit), the JTA timeout must be increased for Oracle B2B. Use the Oracle WebLogic Server Administration Console to increase the JTA transaction timeout to a higher number, depending on your environment. In some situations, the suggested setting is an increase to 90 seconds, and if required, to higher values.

A.1.8 Configuring High-Volume Systems

To improve performance on systems handling a large number of messages per second, the following steps are recommended:

  1. Create a separate table space for the B2B_DATA_STORAGE table so that the LOB data can be stored separately.

  2. Increase the block size for the tablespace for storing LOB data to reduce insert contention.

A.1.9 Settings for Batching a Large Number of Documents

The following are recommended to batch more 1000 documents, where the payload size is greater than 30 KB.

  • Install the SOA server on a 64-bit computer.

  • Set the batch commit size to a value greater than 0, such as 100.

  • Use the Oracle WebLogic Server Administration Console to increase the JTA transaction timeout to a higher value.

  • In setSOADomainEnv.sh, change the heap size setting from -Xms1024m to -Xmx2048m.

A.1.10 Streaming Inbound and Outbound Attachments

To stream attachments from the SOA WS binding layer, add the following properties in composite.xml for services and references:

streamIncomingAttachments="true" streamOutgoingAttachments="true"

Example A-4 shows a sample.

Example A-4 Properties for Streaming Inbound and Outbound Attachments

<binding.ws
port="http://services.otn.com#wsdl.endpoint(MIMEService/MIMEService)"
xmlns:ns="http://xmlns.oracle.com/sca/1.0"
streamIncomingAttachments="true" streamOutgoingAttachments="true"/>
>

A.2 Handling Large Payloads

Oracle B2B can handle large payloads through the SOA Infrastructure and JMS internal queues.

A.2.1 Introduction to Large Payload Support

Inbound Setup

Figure A-2 shows the properties to set for inbound cases. Go to Administration > Configuration.

Figure A-2 Large Payload Size

Description of Figure A-2 follows
Description of "Figure A-2 Large Payload Size"

If a composite is deployed to handle the large payload, this is the only configuration needed. If B2B is not delivering the payload to a composite, set Use JMS Queue as default to true, as shown in Figure A-3. Go to Administration > Configuration.

With Use JMS Queue as default set to true, the payload is delivered to B2B_IN_QUEUE, a JMS-based queue.

Outbound Setup

Figure A-4 shows the properties to set for the outbound case.

Figure A-4 Large Payload Directory

Description of Figure A-4 follows
Description of "Figure A-4 Large Payload Directory"

You must also notify B2B that a service engine is handing over a large payload. The change involves two steps:

The b2b.largePayload property must be set in the BPEL process when sending a large payload to Oracle B2B. For composite samples, which do not handle large payload, there is no change.

Code change in Oracle B2B to handle this flag

  1. Declare the Variable_largePayload variable in an outbound BPEL process in the <variables> section.

    <variable name="Variable_largePayload" type="xsd:string"/>
    
  2. In the Assign activity, copy 'true' into the variable.

    <copy>
     <from expression="'true'"/>
     <to variable="Variable_largePayload"/>
    </copy>
    
  3. Assign the variable to b2b.largePayload in the Invoke activity.

    <bpelx:inputProperty name="b2b.largePayload"
     variable="Variable_largePayload"/>
    

Notes:

If BPEL is not sending a large payload to Oracle B2B, this property should not be set.

Once the code is checked in, any Large Payload Sample must be updated to confirm to this.

In BPEL and Mediator, if b2b.largePayload is set to true, then largePayloadDir must be present (set it in Oracle B2B). If b2b.largePayload is not set, then this directory should not matter.

Oracle B2B retains the large payloads in the large payload processing directory, after sending the payload to corresponding endpoints.

About Large Payload Support

  1. If you are doing large payload testing, set Log Payload on the Administration > Configuration tab to false.

  2. If you are doing large payload testing, set Show Payload on the Administration > Configuration tab to false to avoid listing the payload in reports.

  3. If an enqueue script is used when working with large payloads, add

    eventName=LARGE_PAYLOAD=true
    
  4. Increase the maximum heap size to use -Xmx2048m.

  5. Increase the database tablespace size for soadatasource to have autoextend on and increase the tablespace file size maximum limit.

    alter database datafile '/scratch/$user/auto_work/db230/oradata/db230/SH_soainfra.dbf' autoextend on next 10M maxsize 4096M

  6. Set the transaction timeout in Oracle WebLogic Administration Server:

    • Weblogic Console Services -> JTA Timeout Seconds=720 seconds

    • Weblogic Console Services -> JDBC->DataSources->SOADataSource - increase XA timeout to 120-180 seconds

  7. If Oracle B2B is used alone (without the SOA Infrastructure), the JTA timeout can be set in b2b.jtaTimeout by using Oracle Enterprise Manager Fusion Middleware Control. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for more information.

  8. For an outbound SOA composite, always select the Use file streaming option for the File Adapter, as shown in Figure A-5.

    Figure A-5 The File Adapter Use File Streaming Option

    Description of Figure A-5 follows
    Description of "Figure A-5 The File Adapter Use File Streaming Option"

A.2.2 Large Payloads and 32-Bit Windows PCs

On a 32 bit Windows computer, the payload size limit is 50 MB. This is because the heap size cannot be set to more than 1536m due to Windows-specific limits. Java VM throws an out-of-memory exception.

A.2.3 Settings for a Large Dataset Scenario

The following suggested settings are based on a dataset with approximately 2,500 trading partners, an export ZIP file that is approximately 253 MB in size, and assumes a 6 GB computer. Using these settings can considerably reduce data upload time when using the Upgrade Assistant.

  1. Use Oracle WebLogic Server Administration Console to increase the

    • JTA transaction timeout from 30 to 350

    • Maximum message size from the default size to 200000000

  2. Add indices for better performance. Using Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production, with the Partitioning, OLAP, Data Mining and Real Application Testing options, do the following:

    SQL> create index idx_mds_attr on
    rc1_mds.MDS_ATTRIBUTES("ATT_VALUE","ATT_LOCALNAME");
    Index created.
    
    SQL> create index idx_mds_path on
    rc1_mds.MDS_PATHS("PATH_CONTENTID","PATH_PARTITION_ID");
    Index created.
    
    SQL> commit;
    
  3. Start the managed server with the following updated memory setting:

    DEFAULT_MEM_ARGS="-Xms1024m -Xmx2048m"
    
  4. Change ORACLE_HOME/bin/UA default memory from the default 256 to 2048. The default is

    $JAVA_HOME/bin/java ${JAVAMODE} -Xmx256m -classpath ${CLASSPATH}
    -Dua.home=$base_dir -Dice.pilots.html4.ignoreNonGenericFonts=true
    -Dsun.lang.ClassLoader.allowArraySyntax=true
    -Doracle.installer.oui_loc=$OUI_HOME oracle.ias.upgrade.UpgradeDriver
    $ARGUMENTS
    

    Change the default to

    $JAVA_HOME/bin/java ${JAVAMODE} -Xmx2048m -classpath ${CLASSPATH}
    -Dua.home=$base_dir -Dice.pilots.html4.ignoreNonGenericFonts=true
    -Dsun.lang.ClassLoader.allowArraySyntax=true
    -Doracle.installer.oui_loc=$OUI_HOME oracle.ias.upgrade.UpgradeDriver
    $ARGUMENTS
    
  5. Change the value of Stuck Thread Max Time from 600 to 2000.