19 Performance

This chapter discusses the performance characteristics of RSB, the factors that affect it, and a process to test it.

Performance of RSB within a customer site is critical to the performance of the business, and is determined by factors specific to a given deployment. Because of this is, a Performance Test is recommended as part of every deployment plan. Even if formal testing is not planned, the use of the tools and processes discussed can measure the relative performance of the RSB sub-system and can be used to diagnose bottlenecks.

It is beyond the scope of this document to discuss all of the tools and techniques available at the host, network, database, and application server level.

Performance Factors

The performance of each of these components is influential in the overall performance of the system:

• The application server(s) topology and configuration.

• The RSB deployment approach.

• The hardware sizing and configuration of the RSB hosts.

• The hardware sizing and configuration of the applications that are connected to the RSB.

There are other factors that determine the performance of the overall system. Some of these factors in a RSB environment are:

• Number of managed servers in the cluster

• Number of service calls

• Size of the payload

• Database clustering

Cluster Deployment

RSB needs to be installed in a cluster. A cluster configuration allows for horizontal scaling. Managed servers can be added or removed depending on the volume of transactions and performance requirement. Also, customers can configure different load balancing algorithm to suit their needs.

Enabling/Disabling Instrumentation

If the performance drop is due to heavy instrumentation, the instrumentation can be turned off or set selectively to a minimum level. Also, unnecessary auditing can be turned off for services to improve performance.

Purging

Some of the data gets accumulated over time. Purging or archiving unnecessary data helps system performance.

RSB Service Activity Table

Service Activity table adds a row for each invocation of the service for which trace is enabled. If audit is enabled, the payload is also persisted into the database. Depending on the business need, unnecessary growth of this table should be controlled by regular purging.

RSB Service Activity is a high volume, denormalized table and is expected to grow into a significant size, measures should be taken to manage and monitor the table on frequent basis depending on the consumer's Data lifecycle management policies. Un-monitored, undamaged RSB Service activity table overtime can lead to significant issues not limited to slow system response, database instance issue, database crash and others.

Some of the recommendations are:

• Partitioning strategy: Date Partitioning on the table (one of the partition schemes).

• Data Purging. Purging of RSB SERVICE ACTIVITY should be done at the partition level. Dropping or truncating a partition would perform far better than a delete statement. Global indexes will have to be maintained/updated as well;

• Collection of statistics on a frequent basis.

• Data Archiving.

• Parallelization of queries.

How to Calculate Schema Size?

The service activity table can grow fast depending on the number of transaction and trace and audit configuration. The growth rate and size requirement varies by the type of retail business. It is recommended to estimate the size requirement for your enterprise in the beginning.

Size required (MB) = number of days of data retention * average number of transactions per day * average record size (MB)

You may use the following SQL to calculate the average size of a row, if you have sufficient data in the service activity table.

select
 avg(nvl(vsize(activity_num),0) +
     nvl(vsize(activity_state),0) +
     nvl(vsize(application_name),0) +
     nvl(vsize(business_operation_name),0) +
     nvl(vsize(BUSINESS_SERVICE_NAME),0) +
     nvl(vsize(BUSINESS_SERVICE_URI),0) +
     nvl(vsize(ERROR_CODE),0) +
     nvl(vsize(ERROR_DETAIL),0) +
     nvl(vsize(ERROR_REASON),0) +
     nvl(vsize(MESSAGE_ECID),0) +
     nvl(vsize(MESSAGE_FAMILY),0) +
     nvl(vsize(PROXY_OPERATION_NAME),0) +
     nvl(vsize(PROXY_SERVICE_NAME),0) +
     nvl(vsize(PROXY_SERVICE_URI),0) +
     nvl(vsize(REQUEST_TIMESTAMP),0) +
     nvl(dbms_lob.getlength(REQUEST_XML),0) +
     nvl(vsize(RESPONSE_TIMESTAMP),0) +
     nvl(dbms_lob.getlength(RESPONSE_XML),0)
     ) "Average Size(Bytes)"
from 
    rsb_soainfra.rsb_service_activity 

WebLogic Data Retirement Policy

WebLogic data retirement policy may have impact on the performance of server. If the RSB system has a lot of alerts and statistical information accumulated over time, the old data needs to be retired to keep the performance optimal. RSB ships with a default data retirement policy. This is disabled by default.

The default data retirement policy is set with a Retirement Age of 72, Retirement Time of 1 and Retirement Period 12. This means retire data 72 hours or older. Start the first run from 1:00 am and repeat the process every 12 hours after that.

If the customer wants to use this policy, they can enable the policy through WebLogic Admin Console. Following steps show how to enable the data retirement policy.

1. Click Diagnostics.

2. Click Archives.

3. Click AdminServer.

4. Click Lock & Edit, if needed.

5. Select the policies BusinessAlertDataRetirePolicy and SLAAlertDataRetirePolicy.

6. Click b.

7. Click Release Configuration, if needed.