Performance Profile at a Glance
The diagram below shows the main factors that drive risksheet load time, in rough order of impact. Use it to decide where to focus when investigating a slow sheet.
Load Time and Sizing
Why does my risksheet take up to two minutes to load?
Why does my risksheet take up to two minutes to load?
Multi-minute load times are almost always caused by one of two issues: unresolvable linked work items (broken cross-project references) or too many item-link columns in a single sheet. Both make the server do disproportionate work for every row when building the grid. Check the Polarion server log first for stack traces around the time of a slow load; if you see exceptions related to resolving linked items, that is your root cause. See Common Troubleshooting for diagnostic steps.
What causes the biggest slowdowns: rows or columns?
What causes the biggest slowdowns: rows or columns?
Column count, specifically item-link and
multiItemLink columns, has a much larger impact than row count. A sheet with 250 rows and 17 linked-item columns (7 of them multiItemLink) can be noticeably slower than a sheet with several times more rows and fewer link columns. Each linked-item column triggers additional work item lookups per row, and that cost compounds.Is there a recommended row count limit?
Is there a recommended row count limit?
There is no hard limit, but performance scales much better when you keep sheets focused. Sheets in the low hundreds of rows generally load quickly when columns are well chosen. If you find yourself well above that and the sheet is also column-heavy, splitting by methodology or scope is usually a bigger win than trying to optimize row count.
Sheet Design for Performance
My single FMEA sheet combines usability and design analysis. Is that a problem?
My single FMEA sheet combines usability and design analysis. Is that a problem?
It can be. Combining multiple Failure Mode and Effects Analysis (FMEA) variants — for example usability FMEA and design FMEA — in a single sheet tends to push the column count high, because each variant adds its own columns and links. The recommended optimization is to split one large sheet into dedicated sheets per FMEA type. Each sheet ends up smaller, faster, and easier to review. See Risk Management for guidance on structuring methodology-specific sheets.
There is no fixed threshold, but if a sheet has many item-link columns and several
multiItemLink columns, expect load time to grow noticeably. Treat each multiItemLink column as a significant cost, and ask whether the relationship truly needs to be visible in this sheet or whether it can live on an upstream document. See Column Configuration for column-design patterns.Are saved views a faster alternative to splitting a sheet?
Are saved views a faster alternative to splitting a sheet?
Sometimes, yes. A saved view limits which columns are displayed for a given workflow stage, which can reduce client-side rendering work. However, saved views do not reduce the underlying data the server must assemble — if the slowness comes from resolving links, switching views will not help. Use views for workflow staging; use sheet splitting for true performance relief. See Reference: Configuration Examples.
Concurrency and Multi-User Use
How does Risksheet behave with multiple concurrent users?
How does Risksheet behave with multiple concurrent users?
A risksheet is editable by multiple users at the same time, but each open instance pulls its own data from Polarion. With heavy sheets (high column count, many linked items), concurrent users compound the load on the Polarion server. If you see slowdowns only when several users are active, the bottleneck is more likely on the Polarion server side than in Risksheet itself.
Risksheet does not maintain a separate data store. Every read and write is against Polarion work items, subject to Polarion authorization. That means Polarion server health, indexing state, and authorization checks all directly affect risksheet load time.
Diagnosing Slowness
How do I tell whether the slowdown is Risksheet or Polarion?
How do I tell whether the slowdown is Risksheet or Polarion?
Start with the Polarion server log. If you see exceptions related to unresolvable work item references occurring during grid load, the cause is broken cross-project links rather than the sheet itself. If you see general Polarion slowness — database reindexing in progress, long-running queries on unrelated documents, high CPU — then Risksheet is downstream of a server issue and tuning the sheet will not help. See Common Troubleshooting.
Can Polarion server operations like reindexing make Risksheet slow?
Can Polarion server operations like reindexing make Risksheet slow?
Yes. Historical database reindexing and similar Polarion server maintenance operations can make every work item read slower, which Risksheet feels acutely because it reads many work items per page load. In documented cases, what looked like a Risksheet performance problem turned out to be a Polarion server misconfiguration. Always check whether scheduled maintenance is running before drilling into sheet configuration.
What should I do about broken cross-project links?
What should I do about broken cross-project links?
Find them and fix them. Unresolvable linked work items — items that no longer exist or are inaccessible to the current user — cause expensive exceptions every time the grid tries to assemble that row, and the cost can dominate page load. Review item-link columns for stale references, clean up links to removed work items, and verify cross-project access for users who report slowness.
Optimization Checklist
| Action | When to apply | Expected benefit |
|---|---|---|
| Split combined FMEA sheets by methodology | Sheet mixes multiple analysis types | High — fewer columns per sheet |
Reduce multiItemLink columns | Several multi-link columns in one sheet | High — fewer per-row lookups |
| Clean up broken cross-project links | Server log shows resolve errors | High — removes per-row exceptions |
| Use saved views for staged workflows | Different users need different columns | Medium — less client rendering |
| Check Polarion server maintenance state | Slowness coincides with admin tasks | Diagnostic — rule out server cause |
| Reduce row count | Sheet is very large and column count is already minimal | Low — usually not the bottleneck |
The optimal split point between sheets, the right number of
multiItemLink columns, and acceptable load times all depend on your Polarion deployment, hardware, and user load. Treat the guidance above as starting points and measure in your own environment.