> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Performance Questions
> Common questions about Nextedy RISKSHEET load times, scaling behavior, concurrent usage, and how to diagnose slowdowns.
Load time is driven far more by the **number of linked-item columns** (especially `multiItemLink`) than by the number of rows. If a sheet feels slow, look at column count and broken cross-project links **before** worrying about row count.
## 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
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](/risksheet/faq/troubleshooting-faq) for diagnostic steps.
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.
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
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](/risksheet/guides/risk-management/index) 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](/risksheet/guides/columns/index) for column-design patterns.
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](/risksheet/reference/examples/index).
## Concurrency and Multi-User Use
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
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](/risksheet/faq/troubleshooting-faq).
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.
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.
A single unresolvable reference may not be noticeable, but dozens across many rows can turn a sub-second page load into a multi-minute wait. Sweep stale links periodically, especially after project moves or work item deletions.
## 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.