C Tuning Your Server

This appendix describes steps that can be taken to improve the throughput of the servers. The emphasis is on running DSA jobs as fast as possible.

Checking the Job Results

The most accurate way to check the timing is to place a timer around the calls to run the DSA. Another way is to look at the results of the job in the Administration Server web page and check the duration of the job. See "Viewing Job Status".

Oracle DataLens Server Options

This section contains suggestions about tuning your Oracle DataLens Server.

Load-Balancing the Servers

When you have created a server group of two or more Oracle DataLens Servers in a single server group, the server group provides automatic load balancing and fail-over for all servers within that server group.

When running the application, be certain to call a production servers in the server group and do not call the Administration Server.

Manual load balancing can be performed for the servers in a single server group by selecting which data lenses are loaded by each server. Additionally, servers can be set to load DSA on a server-by-server basis. It is recommended that each server be setup with all the data lenses and DSAs and allow the Oracle DataLens Server to control the load balancing internally.

Round Robin Calls

When running DSA jobs from an application using the API, the Ping Servlet can be used to check for an active Oracle DataLens Server within a server group before making the call.

Ensure Tracing is Turned Off

This is turned off by default. Tracing is only turned on to trace information flow in the system. See "Setting Packet Tracing".

Additionally, there are a set of scs.trace.network flags that should be omitted or set to false in the server.cfg configuration file. See "Server.cfg".

DSA Optimization

This section contains suggestions about tuning the how your DSAs operate on your server.

Jobs Time Out

If your jobs do not process to completion, it is possible that the WebLogic Server domain Java Transaction API (JTA) setting is set to low so that the job is unable to respond in the proper amount of time. The error that is displayed for the failed job is similar to the following. See "Viewing Job Details".

javax.ejb.EJBException: BEA1-05C6C56E971728FAABAA: weblogic.transaction.internal.TimedOutException: Transaction timed out after 32 seconds

You can correct this in your WebLogic Server Administration Console by changing the Timeout Seconds option in the JTA configuration of your WebLogic Server domain. For more information about setting this option, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help 11g Release 1 (10.3.6) at

http://docs.oracle.com/cd/E23943_01/apirefs.1111/e13952/taskhelp/jta/ConfigureDomainJTA.html

Simplify the Data Service Application Process Steps

Each step in a DSA incurs additional overhead. This is because there is job information stored in the RDBMS repository for each the step of a DSA. Additionally there is overhead to package-up and ship the SOAP data contents from the DSA to each step during processing. What this means is that simplifying the DSA structure and placing as much of the process flow inside of Decision Maps will improve the speed of execution. We have observed timing improvements of up to .2 seconds for each DSA step that is replaced with a Decision Map.

Running Ultra High-Priority Jobs

Ultra-high priority jobs are supported. These DSA jobs do not store the step information in the RDBMS repository. The overhead of job execution is eliminated at the expense of job information and details of completed jobs. Especially for single-line jobs, ultra-high priority makes sense because the job execution will be as fast as possible and job details on thousands of single-line jobs will congest the DSA Job Status panel.

Run Jobs at the Correct Priority

The rule is that huge jobs should be run with a low priority, giving processing cycles to smaller medium and tiny high priority jobs. DSA jobs with a small number of input records and jobs where the user is waiting for a response need to be run at a high priority to get the fastest response time.

File Writing Between Steps

By default, when a DSA is being processed by the Oracle DataLens Server, all data will be held in memory, unless there are more than 5000 records being processed in a single DSA job. The speed of execution of these large jobs can be increased by setting the number of data records that are held in memory between these processing steps. This is controlled in the Oracle DataLens Server.cfg file with the following line:

wfg.maxlines=150000

Data Lens Optimization

This section contains suggestions about tuning your data lenses.

Caching the Data Lenses

Individual data lenses can cache parsing rules in memory for re-use without re-loading the rule each time. This is mostly useful for data processing by data lenses that reuse the same data repeatedly. Examples of this would be manufacturer names, redundant data, part numbers that are reused often. Data lenses that are not a good candidate are those that process things like descriptions that are different each time and would require a different parse tree for each line.

The cache should be large enough that the most often repeated lines are allowed to stay in memory (using a LRU Queue where the least often used rules will drop out of memory). For instance if there are 300 manufacturer names that are often reused among several thousand names, then the cache should be set to 1000 or perhaps 2000 depending on the frequency of use, to ensure that the 300 most often used names continue to reside in memory.

This is change is required for each data lens that need the caching.

Check out the data lens to the client
Go to the C:\Datalens\Applications\data\user_name\project\data_lens_name\config directory
Edit the project.xml file and modify the following line to the cache size
```
<parseTreeCacheSize>0</parseTreeCacheSize>
```
Save and check-in the project after making this change.

Do Not Load Data Lenses That Are Not Being Used

When running in a production environment, the number of data lenses is controlled by the lenses that are deployed to Production. Do not deploy data lenses to Production if they are not going to be used for actual production DSA jobs.

Fine-tuning of which data lens are used by a particular server can be controlled by undeploying the particular data lenses that are loaded by a particular Production Oracle DataLens Server. See "Viewing Data Lens Details and Managing Deployment".

Tuning Multiple Parameterized Domains

Set the number of parameterized domain instances that will be loaded into memory. A single domain with two instances should set instances to three to maximize performance when using these domains.

One for the first parameterized domain
Another for the second
A third for both in memory

This is set in the server.cfg file as follows:

server.nle.instances=3

Optimizing Hardware and Operating Systems

This section contains information about optimizing hardware and operating systems for improved performance.

Windows Memory and Application Servers

For information on the memory limitations of Windows machines, see "Memory Allocation Problems on Clients".

Linux and Unix Memory, Windows Memory, and Java Servers

Linux and Unix running on 64-bit hardware does not have the 1.6 GB memory limitation for Java Web Server that we have observed on 32-bit Microsoft Windows servers. Windows 64-bit servers do not have this memory limitation either.

Important:

In an Enterprise DQ for Product production environment, only run on a 64-bit server running a 64-bit installation of Java. Never try to run a production environment on any 32-bit servers.

Database Query Tuning

In database-intensive DSAs, major performance improvements can be made by tuning the database DDL statements. Simple things like indexing fields that are being searched on and reducing the number of tables in computationally intensive SQL joins can be very effective in improving the performance of the DSAs.

These tuning tasks are very dependent on the particular database schema and should be examined by a database professional.