Performance Tuning, Troubleshooting, and Monitoring
Where time goes
Performance work starts with the query: filters on indexed fields (primary key, external ID, email), date windows on log tables, and avoiding LIKE '%term%'. Workflow temporary tables grow when keep results is enabled or when a recurring workflow never purges. Deliveries are bounded by MTA throughput, IP affinity and wave scheduling, not by the workflow alone. Monitoring uses workflow logs and audit, delivery alerts, bounce and tracking logs, and technical workflows that purge and aggregate data. Understand incremental versus full queries - incremental queries keep the work table small.
Traps
- A query on
nms:broadLogwithout a date filter scans huge volumes and can time out. - Restart from a failed activity does not re-run upstream population; stale temporary data may be used.
- Increasing log level does not improve speed and can slow a busy instance.
- A delivery stuck in pending may be a routing or external account problem, not a performance one.
- Deleting a workflow does not delete its historical logs; purge separately.
Rule of thumb
Before optimizing code, capture the query plan and row counts: filter on the primary key or a date-indexed column, then reduce columns with $select or a narrow query. If a workflow runs daily, make it incremental and purge work tables.
Worked example: A nightly send takes six hours. The query filters [email] LIKE '%@example.com' on all recipients. Replace with [domain] = 'example.com' plus [lastModified] >= SubDays(GetDate(),1), add a Deduplication, and enable incremental mode. Runtime drops to minutes because the work table is smaller and the filter can use an index.