Performance and finetuning (OP)

This section describes how you can optimize the performance of the Data Upgrade Engine ( DUE).

The performance of the DUE is influenced by:

You can use the Call Graph Profiler to identify potential performance bottlenecks. See Using the Call Graph Profiler.

Runtime class

During initialization of the DUE run, the upgrade programs determine their runtime class. This is based on factors such as parameter settings, table sizes, and source feature pack. Common rules are used. For your specific environment there may be factors that lead to a not optimal determination of the runtime class. As a result long running tasks may be scheduled later than small tasks. This causes a longer total elapsed time.

We recommend to perform a test upgrade run before you start the real run. You can analyze the results of the test run, and optimize the running class where necessary. Complete these steps:

  1. Perform a test run. See Executing a data upgrade run (OP-CE).

    For a realistic test, perform this test run on companies that are copied from the real live data companies.

  2. Print and analyze the results of the test run.

    1. Start the Print Data Upgrade Run Information (ttspt2400m000) session.
    2. Select the Data Upgrade Run Information [Flat File] report and print the data of the test run to a file.
    3. Optionally, import this file in MS Excel.
    4. Analyze the results. Per upgrade task, view the runtime class and the duration.

  3. Optimize the running class in these situations:

    • A task, which lasts long, has a low running class.

      Select a higher running class for the task.

    • A task, which takes a short time, has a high running class.

      Select a lower running class for the task.

      For example:

      • A task has running class Medium and lasts 3 hours. Change the running class to Large or Huge.
      • A task has running class Huge and lasts only 30 minutes. Change the running class to Large or Medium. Other tasks will take advantage of this.

    The duration of an upgrade task differs per company because it depends on many variables. Therefore, for each company or set of companies, it is important to investigate the maximum duration of an upgrade task before you change the runtime class.

Additional servers
Caution!

If the whole system capacity can be used for the DUE, we recommend to specify one additional bshell per CPU. For example, if your LN server contains 8 CPUs, specify 8 additional bshells.

The DUE is very high CPU intensive and other users are hampered when the number of additional upgrade tasks is too high. Therefore reduce the number of additional bshells if not the whole system can be used for the DUE.

In the Number of Additional Servers field in the Data Upgrade Engine (ttspt2201m000) session, you can specify the number of additional bshells that will be used to run the Data Upgrade Engine.

Additional bshells can greatly improve the performance of the DUE because several upgrade tasks can be started in parallel.

The additional bshells perform a lot of I/O actions. It is not recommended to add more bshells than the I/O subsystem can handle. If you do not know the I/O capacity of the I/O sub system, as a rule of thumb, specify one additional bshell per CPU.

Note

If you set the Number of Additional Servers field to 0, the DUE is run in a single bshell.

Using the local server for processing

When you use additional bshells, the local bshell , where the Data Upgrade Engine (ttspt2201m000) session is started, schedules the upgrade tasks. This local bshell gathers the list of upgrade programs that must be executed and spreads the work over the different bshells.

If you select the Use the local Server for processing check box in the Data Upgrade Engine (ttspt2201m000) session, the local bshell will not only schedule the upgrade tasks but will also run upgrade tasks.

We recommend the following:

  • Select the Use the local Server for processing check box if you select 1 additional bshell in the Number of Additional Servers field.

  • Clear the Use the local Server for processing check box if you select more than 1 additional bshell in the Number of Additional Servers field. The local bshell only schedules the upgrade tasks. If the local bshell also had to run upgrade tasks, it might be too busy to schedule tasks for the different additional bshells in time.

Using sub-tasks

Some long running upgrade tasks have sub-tasks. These sub-tasks are defined in the upgrade programs delivered by Infor and are created during the initialization of a DUE run. Each sub-task has its own data range to perform a part of the upgrade task. To improve the performance of the DUE, sub-tasks can be run in parallel in different bshells. If a task is sub-task enabled, you can manually add, change, or remove sub-tasks. See the online help of the Sub-Tasks (ttspt2535m000) session. This session runs in a tab in the Data Upgrade Tasks (ttspt2520m100) details session.

Using the Call Graph Profiler

To identify potential performance bottlenecks, you can run the Data Upgrade Engine with the Call Graph Profiler activated.

To view the generated files, use the Files (ttspt2530m000) session. The names of the generated files have this format:

profile.[bshell.pid].ttspt2203m000.[pid].html

To use the Call Graph Profiler, start the Debug and Profile 4GL (ttadv1123m000) session and select the Profile Mode check box.

For details on the Call Graph Profiler, see these documents:

  • Infor LN - Performance, Tracing and Tuning Guide
  • Infor ES Programmer's Guide

Related topics