Performance and troubleshooting
What the exam tests
This domain tests whether you can measure before optimizing, diagnose slow screens and integrations, use OutSystems monitoring and logs, and fix root causes without destabilizing the solution.
Core rules
- Start with evidence: Service Center monitoring, error logs, integration logs, browser developer tools, and timers. Reproduce in a non-production environment.
- Database: index filter and sort columns; filter in aggregates rather than in client-side logic; set Max Records and pagination; avoid unbounded queries and N+1 access patterns.
- UI: reduce data returned to screens, paginate lists, and avoid heavy logic in OnReady or on every render.
- Integrations: set timeouts, handle failures, and move non-critical work to asynchronous processing or timers.
- Cache reference data only after identifying the bottleneck; define invalidation so stale data is acceptable.
Worked example
A customer list screen is slow. The aggregate returns 10,000 rows and the client filters them. Fix it by filtering by the search parameter in the aggregate, adding an index on the filter column, enabling pagination, and setting Max Records to the page size. Measure response time before and after. Reasoning: the bottleneck is data volume and filtering location, not rendering; caching first would hide the problem and add staleness risk.
Traps that cost marks
Adding cache before profiling; missing indexes; unbounded aggregates; ignoring integration timeouts; debugging in Production; and treating a UI symptom as the root cause.