For the cases where replication is occurring slowly between your ServiceNow instances, you can do the following to tune and optimize your instances.

ServiceNow's HTTP Client Connection Management limits the number of connections the Perspectium application can make and thus can be a factor in the performance of replication. It is recommended you adjust the HTTP Client Connection Management properties to higher values as shown below to allow more connections to the Perspectium Message Broker Service.

Note if the properties do not exist, see Adding a Property as ServiceNow will use the default values if the properties do not exist in an instance.

The Perspectium Outbound and Inbound message queues in ServiceNow in particular requires indexes to be added in order for Replicator to function optimally. The following table documents all the tables and their indexes that need to be created by an administrator of your ServiceNow instance. Please follow the index creation guidelines in the following ServiceNow wiki article particular to your version of ServiceNow:Creating Indexes in ServiceNow

As of v3.19.0, these indexes are included as part of the update set. However, these indexes will only install properly in Helsinki+ versions of ServiceNow and will show commit errors in older versions. These commit errors can be ignored as the rest of the update set commits will have installed properly.

In Bismuth, indexes have been added to the PSP Attachment Out Message (u_psp_attachment_out_message) and PSP Audit Out Message (u_psp_audit_out_message) tables.

• Since each node will have 8 background workers ideally you only want to use 50% of the scheduled workers for running bulk shares so the instance can continue to run its other background jobs optimally. For example, if you have 4 nodes, then you would have a total of 32 workers available and you only want to use 16 of those workers for bulk shares. If you create a Scheduled Bulk Share and execute it, then all bulk shares in it will execute concurrently. So in the above example, you would only want to have 16 bulk shares in a scheduled bulk share as otherwise anything above will affect performance of the instance in general.

• When running multiple bulk shares or scheduled bulk shares concurrently, try to avoid running ones that have the same parent table at the same time. For example, you wouldn't want to run problem and incident bulk shares at the same time since they both have the same parent table (task). If both are run at the same time, this would cause both bulk shares to run slower due to thrashing of the database as they both query the same tables.

• Disable replicator to add display value fields if it is enabled. Currently, the add display value fields with 'dv_' is OFF by default for optimal performance. This property can be disabled in the Perspectium Replicator Properties page. For more details on display value visit here.

If you receive notification from Support that messages are starting to accumulate on the Perspectium Message Broker Service (MBS), you can add more Perspectium Replicator Subscriber jobs on the subscribing instance that will help improve the performance with reading messages.

Go into Perspectium > Control and Configuration > All Scheduled Jobs and look for the Perspectium Replicator Subscriber scheduled job:

Create another one of these jobs, naming it something such as Perspectium Replicator Subscriber 2 to easily identify it as a second version of the same job. The easiest way to do this is to click into the Perspectium Replicator Subscriber scheduled job, change the Name field to the new name and then right-click along the top toolbar where it says “Scheduled Script Execution” and choose the “Insert” option:

This will create a duplicate of the Perspectium Replicator Subscriber job and you will now have two jobs running to get replication messages from MBS (by default each scheduled job is set to run every 30 seconds but you can adjust these jobs to run at a quicker interval such as 10 seconds in the above screenshot). You can add more jobs as necessary depending on your instance i.e. these jobs will need to compete with other jobs for available workers so if you have too many jobs and not enough nodes/workers, it may take longer to run if you schedule too many.