Why is my Risksheet loading slowly?
Risksheet performance degrades when loading large documents (>500 rows) with complex formulas, multi-level hierarchies, or extensive link role columns. The primary bottleneck is server-side rendering of Velocity macros and JavaScript-based formula calculations executed in the browser. Use the “Progressive Workflow Views” feature in FMEA documents to load subsets of data (e.g., only “In Progress” failure modes), or implement pagination by splitting large risk analyses into multiple documents grouped by system element or product line. See Risksheet Loading Issues for diagnostic steps.
What causes PowerSheet to render slowly?
PowerSheet performance depends on the complexity of expansion paths and the number of linked work items being traversed. A Whole RTM sheet that expands 5+ levels deep (e.g., Customer Requirement → System Requirement → Design Requirement → Test Case → Test Run) with hundreds of items per level can take 30+ seconds to render. Reduce expansion depth by using Component RTM sheets focused on single subsystems, or filter the source query to exclude unnecessary work item types. For details on optimizing expansion paths, see Modify RTM Model.
How can I speed up dashboard rendering?
Dashboard macros like nxLinkCoverage, nxCountByEnum, and nxRiskMatrix execute Lucene queries against the Polarion repository. Performance issues arise when widgets aggregate data across thousands of work items without filtering by project location or revision. Add Lucene filters to widget parameters (e.g., location:Risks/HARA-2024 or type:failureMode AND status:approved) to reduce query scope. Cache frequently-accessed metrics using scheduled jobs that write results to custom fields, then display cached values instead of live calculations. See Customize Dashboard Macros for implementation guidance.
FMEA Risksheet configurations use Velocity formulas to calculate RPN (Risk Priority Number = Severity × Occurrence × Detection) and Action Priority from enumeration fields. Performance degrades when formulas reference linked work items (e.g., traversing failure mode → characteristic → control plan to aggregate detection ratings). The Occurrence rating scale includes 10 levels with Cpk correlation metadata, requiring additional lookups. Optimize by pre-calculating RPN values in custom fields using Polarion workflows instead of runtime formula evaluation. For Action Priority logic based on AIAG-VDA 2019 methodology, see Calculate Action Priority.
What affects report generation speed?
PDF export performance in LiveDoc reports depends on document size, number of embedded risksheets, and complexity of Velocity macros used for data aggregation. A System DFMEA report with 200+ failure modes, embedded risk matrices, and traceability coverage tables can take 5+ minutes to generate. Pre-render static content using cached custom fields, limit embedded risksheet rows using query filters, and avoid nested #foreach loops over large collections. For export optimization techniques, see Export Reports to PDF and Report Generation Failures.
How do I optimize traceability coverage checks?
The nxLinkCoverage macro traverses link roles bidirectionally (e.g., verifies → verified by) to calculate coverage percentages. Performance degrades when checking coverage for 1000+ requirements with 10+ link roles each. Use targeted coverage checks scoped to specific requirement subtypes (e.g., only SC/CC safety-critical requirements) or system elements (e.g., Component RTM filtered by systemElement links). Avoid checking coverage for the entire project in a single macro call. See Check Traceability Coverage for efficient query patterns.
Use this table to identify the right optimization strategy based on your performance bottleneck:
| Symptom | Root Cause | Solution | Reference |
|---|
| Risksheet loads >20 sec | Large document (>500 rows) | Split into multiple documents or use progressive views | Progressive Workflow Views |
| PowerSheet timeout | Deep expansion paths (5+ levels) | Reduce expansion depth or use filtered queries | Component RTM Sheet |
| Dashboard blank/slow | Widget queries scan all work items | Add Lucene location/type filters to widget params | Customize Dashboard Widgets |
| Formula lag in cells | Complex Velocity formulas with link traversal | Pre-calculate in custom fields via workflow | Configure Custom Formulas |
| PDF export >5 min | Large LiveDoc with embedded risksheets | Limit risksheet rows, cache aggregated data | Export Reports to PDF |
| Coverage checks timeout | Project-wide link role traversal | Scope to system element or requirement subtype | Check Traceability Coverage |
For immediate improvement, enable browser caching for risksheet JavaScript modules and dashboard Velocity scripts. Add Cache-Control: max-age=3600 headers to .js and .vm files in .polarion/pages/ using web server configuration. This reduces repeated downloads of the Risksheet Traffic Lights Module and Driver.js Tour Library on every page load. Can I profile slow Velocity macros?
Polarion does not include built-in profiling for Velocity templates, but you can add timing instrumentation to custom macros. Wrap macro execution in #set($startTime = $dateTool.systemTime) and log execution duration using $polarionLog.info("Macro X took ${math.sub($dateTool.systemTime, $startTime)}ms"). Check Polarion server logs (polarion/logs/log.txt) to identify slow macros. For critical macros like nxFmeaElementBlock or nxDocInventoryTree, consider migrating complex logic to server-side Java services exposed via REST API. See Nextedy Solutions Macros for architecture patterns.
Unfiltered Lucene queries (type:workitem without location constraints) can scan 100,000+ work items in enterprise Polarion repositories. Always add location filters (location:Risks/* or location.ancestor:Risks) to scope queries to relevant spaces and reduce database load.
