Workload unit spikes from nested searches
A search inside each row of a repeating group runs once per row, so one page load can trigger hundreds of searches. Find the expression in App metrics, then replace per-row searches with stored values, constraints instead of :filtered, and counts instead of full lists.
Why nested searches are expensive
The official workload documentation calls nested searches a common source of high WU consumption. Its example is one search for companies, then three searches or counts of employees in each row, which can mean potentially hundreds of searches every time the page loads.
The published starting rates can rise with complexity and the amount of data returned. A database search starts at 0.3 WU, each thing returned at 0.015 WU, and an aggregate query such as a count at 0.2 WU. Multiply that by every row and every visitor and the bill climbs quickly. The documentation also states that the total size of your database does not increase the WU cost of a search. The problem is how many searches you run and how much they return, not how much data you store.
The :filtered operator makes this worse. The official optimization checklist advises avoiding it, especially with advanced filters, because an advanced filter can mean one extra search per item.
How to find the culprit
- Open Logs, App metrics and look at the Workload usage chart for the spike.
- Open Workload by activity and drill down. Clicking a search item takes you to the expression in the editor.
- Use Server logs to see WU per workflow and per action if the cost comes from backend work.
How to fix it
- Store aggregates instead of recounting. Add a number field, such as an employee count on the company, and update it when employees are added or removed. Each row then reads one field instead of running a search.
- Use constraints, not :filtered. Move conditions into the search constraints so the database does the work in one query.
- Ask for a number when you need a number. Use :count or :average instead of returning a full list to the page.
- Do not repeat searches in workflows. Identical searches on a page run once, but the official manual notes that repeating the same search in a workflow runs the query again. Save the result to a custom state or field and reuse it.
- Re-measure. Compare App metrics before and after over the same traffic period, so you know the change worked.
Triage / $99
Approximately 1 hour of work. Determining issues and coming back to you with a plan.
Pay $99 and book