This article explains some tips to optimize Pulse performance in a large environment (10+ TM1 instances).

Before reading through this article, you should be familiar with the following articles:

• Pulse 6 Architecture

• Pulse System Requirements

• Getting Started with Pulse 6

In this example, we have three environments DEV, UAT and PROD with 2 servers each and each server with 3 IBM Planning Analytics (TM1) instances so 18 instances in total.

The Pulse Application Server uses the TM1 REST API to connect to each TM1 instance therefore it does not need to be installed on each TM1 server. It is recommended to install Pulse on its own server but if one server is not available, you can install it on one TM1 server as long as there is enough memory and disk space available according to the Pulse system requirements.

⚠️ More resources are required by Pulse 6 vs Pulse 5, please check the new system requirements before installing Pulse:

• System requirements

In our example, we chose to install the Pulse Application on its own server and one Pulse Monitor on each TM1 instance.

One Pulse Application Server can monitor many TM1 instances. In best case scenario you will end up with the architecture below, one Pulse to monitor all the TM1 instances:

Even though one Pulse Application Server can monitor many TM1 instances from many servers, if your environment is large (20+ TM1 instances), one Pulse Application Server will need a lot of memory to monitor everything.

It is difficult to estimate in advance because it will depend on how many sessions and logs each instance is generating.

Each second Pulse is going to retrieve all the sessions, logs and metrics such as cpu, ram for all instances.

If you want to keep one Pulse to monitor all your TM1 instances there are few tips that you can apply to optimize Pulse performance:

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 and having the MaximumPulseDiskSpaceGB set to a relevant value for your environment.

• Cleansing Pulse data

If you have tried all the tips above and you are limited in terms of memory that you can allocate to Pulse then you will just need to install multiple Pulse. For example below, to monitor 18 TM1 instances, we ended up with 3 Pulse, one per environment (DEV, UAT and PROD):