...
- For pages with no requirements, we've improved the speed by skipping our indexation:
- We skip the parsing if the storage format hasn't changed,
- We skip the parsing if the rendered format hasn't changed, in case it contains an "Include" or "Scaffolding" macro.
- We skip the parsing if there is no requirement in the old or new version.
- For pages with requirements:
- We've added indexes on database columns. On our instance we get 5x faster results when saving a page, but we may be in special circumstances.
- When we index a page (=when a user saves a page), we've batched the lookups of requirements, so we don't do 1 database request for each requirement on the page. On our instance, we get again 4x faster times depending on database latency (most LANs are on 1ms latency, but we've measured with 5ms).
- We'd be thrilled if you have 20x better response times than in 1.11.4, but we'll check back with customers before asserting that.
Performance change in 2.0
- We've deeply modified the indexing algorithm in 2.0, because we are now importing Excel files.
- This algo generally reads first and checks whether it needs to change the data, instead of deleting all and writing blindly.
- We did not notice much change in speed. Some speeds are improved, other are worse, depending on the number of modified requirements and properties.
Details
We have evaluated on a personal machine with the following setup:
...
Event | Time (in addition to Confluence's algorithm). For ~400 requirements, ~525Kb text per page, 2ms network latency. No Jira connection. | Time 1ms latency, |
---|---|---|
Page creation |
|
|
Page edition |
|
|
Submission of excerpts (This operation is in the background, the user doesn't wait for this). |
|
New result:
|
Tested for Requirement Yogi 2.0.0 with 2ms and 1ms network latency, in addition to the database latency, already loaded with 80.000 requirements. |
...