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.

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:

• Pulse database migration into MS SQL Server

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.

• Making TM1 REST API queries 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:

• To stop downloading elements during documentation

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:

• Choose which instance needs to be monitored by Pulse

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

• Increase Pulse JVM Max memory

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

• Increase Elasticsearch JVM Max memory

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:

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:

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:

• Cleansing Pulse data

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

• Connecting Pulse to PA SaaS with the non-interactive account

• Pulse Installation Guide