How can custom queries slow or kill TRIRIGA performance?

Depending on how you create your queries, custom queries can have an impact on the performance of your system. In your custom query, when you create an Association Filter, you want to avoid using –Any– for the module selection and avoid All for the business object selection. The reason to avoid those particular selections is that they can cause potential report performance issues. This is mentioned in the IBM TRIRIGA 3.4.2 Reporting User Guide. It is better to specify a specific association type in your Association Filter than to use –Any–.

If you have any fields that have a special character in them, like < > , & * or -, that can also impact your performance. While field names should not have < > , & * or – in them, it could happen somehow. If any of your fields manage to have special characters in them, then this is going to cause an issue, because the reports will not be built. So it is a good idea to avoid special characters. If you do have special characters in any of your field names, it is best not to have it referenced in a query. But, ideally, you will want to create field names that do not use a special character.

It is important to note that if you have modified your custom queries, you need to clear the Query Cache in the TRIRIGA Admin Console for the change to take effect.

Continue reading

Why doesn’t the organization hierarchy tree get displayed?

So I wanted to reload our Department and Division data in our Dev environment. All the records were in Draft state. I opened the Department form and selected all my records and clicked on the Delete button. Then I did the same with the Division form and clicked the Delete button, which just state-transitioned those records to a null state. Then I went to the Organization Hierarchy quick link from my portal. Now the tree doesn’t display and I get the following error:

“Please contact your system administrator. The tree control reported this error while trying to draw itself: There was an error in the database or the query definition.”

I thought it could be the cache. So I went into the Admin Console > Cache Manager, and refreshed the “Hierarchy Tree Data” and “Hierarchy Tree Data – with rebuild”. I checked the “Hierarchy Tree Cache Status”. The Organization hierarchy has not completed yet and the duration has been over 20 minutes. I only have less than 500 Department records and 20 Division records. So I am concerned that the rebuild shouldn’t take that long. How do I query or get the Organization hierarchy tree data back in order? Any suggestions?

So it looks like the only way to remedy this error is by retiring the records, and then deleting the records (which sets the TRIRECORDSTATESY to null), and then letting the Cleanup Agent run. After I did that, the Organization hierarchy was displaying correctly.

[Admin: This post is related to the 04.07.16 post about a corrupted cost code hierarchy, and the 06.18.15 post about the hierarchy tree cache taking a very long time to rebuild.]

Continue reading

What are the recommended maximum threads in IBM TRIRIGA?

What are the recommended values for maximum threads in the IBM TRIRIGA Admin Console > Thread Manager page? I need to set up maximum threads for better performance without causing problems to my system.

To control the number of threads that are started for each agent, use the Threads Manager menu in the IBM TRIRIGA Administrator Console. A single thread requires one connection to the database. A large value for the total of maximum threads can slow performance. As a guideline, a typical limit is no more than 2 to 3 times the core count of the database server. One must also add the number of servers and agents connected to the database.

If there are multiple Workflow Agents running against the same database, the sum total threads across all servers should not be more than 2 to 3 times the total core count of the database. As a reminder, the only scenario recommended for having multiple Workflow Agent instances running is when you have a User List associated to them. See more information in this wiki page: When to use Multiple Workflow Agents. For example, if the database has two Dual Core Xeon CPUs, the core CPU count is four (4 CPUs). So, you should have up to 12 threads connecting to the database (3 x 4 CPUs).

However, you have only a process server with a single Workflow Agent instance running as part of your topology. As such, you may share the 12 threads in this way when setting the Maximum Threads in the IBM TRIRIGA Admin Console > Threads Manager:

  • CAD Integrator: 2
  • Data Import Agent: 2
  • Scheduler Agent: 2
  • Workflow Agent: 4
  • Report Queue Agent: 2

[Admin: This post is related to the 05.06.15 post about when to use multiple workflow agents.]

Continue reading

What is your ongoing process for TRIRIGA performance tuning?

Being on the IBM TRIRIGA Support team, I have seen my share of PMRs where the customer is reporting a performance issue… First and foremost, I need to make it clear that performance can be affected by a wide range of components… Second, you should review the Best Practices for System Performance… Third, as a TRIRIGA Administrator, you should review performance on a regular basis…

But your best tool for analyzing TRIRIGA performance is the performance log…

  • 1) Login to the Admin Console.
  • 2) Click on Platform Logging in the Managed Objects section on the left side of the screen.
  • 3) On the right side of the screen is a list of categories that have a hierarchical structure. Scroll down to the Performance Timings category.
  • 4) Click on the check box immediately in front of Performance Timings. This will cause all of the subcategories to be checked.
  • 5) Scroll down to the bottom of the page and click on the Apply button.
  • 6) At this point, performance logging is turned on and the performance.log file should appear in the TRIRIGA directory structure in the log sub-directory.
  • 7) Perform activities that users have indicated are poorly performing. This action, along with other actions taking place at the time of the testing, will get logged to the performance.log file.
  • 8) Once you have completed the process of recreating the performance issue, log back into the Admin Console and turn off the performance logging.
  • 9) Perform an analysis of the resulting performance.log…

[Admin: To see other related posts, use the Performance tag or Tuning tag.]

Continue reading