Field Sync listens to ALL update events on Jira issues and triggers the Listeners defined (and enabled) on your system for each update. The following are the things to consider for optimizing Field Sync on your system.
When Field Sync catches an update on an issue and acts on it, it will update some target issues. All updates made by Field Sync on target issues will also cause update events on those issues and will trigger a second level of update originating from those issues. Those updates may also trigger a third level and so on.
Depending on the link structure of issues and enabled listeners on your system, a single update by a user might trigger many levels of updates on other issues. While this is a good feature to have, it is best to optimize your listener structure to avoid putting to much unwanted load on the server.
Define Project and IssueType
Each Field Sync listener has Project and IssueType definitions for itself. When a listener is triggered by an update, it first checks to see if the updated issue matches its project and issuetype. If the issue does not match, the listeners exits without searching for possible target issues to update.
The listener migth be configured to sync a field used only on some issues so the listener will seem to have no effect on other issues but it will respond to updates and try to find target issues anyway.
It is best practice to define project and issuetype for your listener so the listener won't try to respond to irrelevant issues and cause unnecessary load on the server.
Define Source Issue JQL
If the updated issue matches the listeners project and issuetype, the listener then checks to see if the issue matches the source issue jql defined for the listener (If source issue JQL is empty, it is always a match).
If the listener should respond to a subset of issues that are defined by things other than project and issuetype, you should define a source issue jql. The definition of a source issue jql will also stop the listener from trying to respond to irrelevant issues.
Don't think that you MUST define a source issue jql. If your project and issuetype selections successfully filter your issues, you should leave source issue jql empty so the listener will always consider it a match without running it.
Disable unused listeners
Each listener responds to each update on each issue on your system, even it won't do anything about it. If the update is on an issue in project A and the listener is defined to respond to issues in project B, the listener will still respond to the event but will exit quickly since the project is not a match. Even so, this causes a miniscule load on the server. This might pile up to a significant load for large numbers of issues.
Considering this, it is best practice to deactivate listeners that no longer serve a purpose.
Field Sync avoids loops
Since Field Sync can run multiple levels of sync (as defined above) and since all listener types can be configured for bidirectional sync, one might think that Field Sync might fall in a loop and update the same issues over and over again.
Field Sync has a built in loop avoidance check. It keeps track of all the issue updates through levels triggered by a user action and does not update the same issue twice based on that action.
Field Sync also has limits on updates. It will stop updating target issues if it reaches a max of 50 levels or 1000 issues.
These are built in checks and you don't need to configure anything for this.