Mar 5, 2023

Fine-tuning for Pulse

The pulse default configuration should be enough for most environments. This article shares some tips to improve the performance of Pulse if it slows down.

Migrating to MS SQL Server

The default H2 database is single-threaded. It means that if you have many Pulse users and many TM1 instances. The queries to the database might queue-up. To avoid this, you could migrate to MS SQL Server:

Fine-tuning your TM1 instances

Pulse is mainly making three REST API queries (one to get the sessions, one to get the threads, and one to get the logs). This article shares some recommendations to make these queries even faster.

Make the documentation faster

By default, Pulse is going to download the elements for all dimensions with fewer elements than the maximum number of elements defined in Pulse.cfg (MaximumElements). If you don’t need Pulse to download elements, you should turn this off. By turning this off, the documentation will be significantly faster:

Deactivate some instances

Some TM1 instances might not need to be monitored by Pulse, you can deactivate some instances to reduce the amount of requests Pulse needs to do:

Increase Pulse JVM memory

If Pulse CPU is always very high, you should increase the Pulse Application Server JVM:

Increase Elasticseach JVM memory

If Pulse Elasticsearch CPU is always very high, you should increase the Pulse Elasticsearch JVM:

Increase the State Poll or Message Log Poll intervals

You can reduce the number of requests Pulse needs to do per server. For example, for the DEV instances, you might not need the sessions every second in this case you can increase the State Poll interval and make it run every 2 or 5 seconds:

Spread out the update documentation

By default Pulse executes the documentation for all instances at 1:45 am. If you are working with 10+ instances, this will require a lot of memory and CPU for Pulse. So you could spread out the execution of the documentation by 5-10 min for each instance:

Cleansing Pulse data

When working with many TM1 instances, Pulse is going to store lots of data very quickly, it is very important to be aware of the Pulse maintenance job to manage the size of the Pulse database and the Pulse Elasticsearch cluster:

Using a non-interactive account for PA SaaS customers

For PA SaaS customers, instead of using this IBM ID, Pulse can connect with a non-interactive account. This brings two main benefits:

  1. The requests from Pulse are slightly faster than using IBM ID
  2. The user running the Pulse threads will be a technical user and not an existing IBM ID

 Parent Article:

Related content

Loading related content