Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In the release 3.5, we have introduced the back-end indexing. How should an administrator choose between the two indexing engines?

...

How should a customer prepare the transition to the Indexation V2?

  • Check whether you are using baselines. If yes, make your key users aware that the contents of requirements indexed before and after the move to Indexation V2 won’t be comparable, due to many tiny changes in the output HTML.

  • Check whether you are using the app named “Scaffolding”. If so, then the support for Scaffolding is only implemented in 3.8.3, with limitations described in https://requirementyogi.atlassian.net/browse/RY-1160

What is the recommended setting?

...

Up until version 3.4, requirements would be extracted while they were displayed for the first time. It would produce produced two side-effects:

  • When saving the page, the user would have to wait until we've identified all requirements on the page. It would be seamless and very fast for small pages, but it could be long when there are hundreds of requirements.

  • The Javascript that would extract the requirements from the page, running while the user views the page, was designed to simplify the extracted text. With time, we couldn't change it, because some customers rely on the comparability of extracted texts across versions of requirements. Also, since it was rendered at runtime, there could be slight differences in text that made comparisons difficult.

We keep the Version 1 to allow for more time for our customers to migrate, but, since we now support Scaffolding, we don’t believe anything is holding you back!

What is the engine Version 2, "Using the queue"?

...

No performance impact. The new mode is more lightweight on instanceswas lightening-fast on our test instances for 4 reasons: 1. We don’t make the user wait for the reindexation before displaying pages, since we put process everything in a queue and only 1 thread treats the queue. In our perf tests, it was lightening-fast compared to the version 1, but we’ll wait and get feedback from real-world cases. In the old system, if several users submitted pages, Requirement Yogi would make them wait until the page was reindexed, and it would also process all users at the same time, which meant several threads of Confluence could be kept busy with saving pages (That is, if you have hundreds of requirements per page and megabytes of data to save).

When should you NOT switch to the new mode?

  • When you use requirements in the Scaffolding macro,

  • If you have many baselines and you want to compare requirements created before and after changing modes.

We’ll update this list if we are made aware of other anti-patterns, 2. The queue means only 1 task is executed at any time, ensuring we don’t suddenly parse dozens of pages at the same time, 3. the reindex is much shorter due to the change of architecture, and 4. The algorithm itself is faster at parsing XML (but that may change depending on complexity).

Should an existing customer switch to the new mode?

...

  • YES, existing customers should use the new mode, for the performance.

  • BUT check whether your users rely on have baselines. If they do, do they expect to compare requirements across baselines? If so, keep the Legacy JS mode.BY DEFAULT… Given the above item, we have choosen that existing customers will have the Legacy JS mode by default. Only administrators who wish to move to the new mode will do it manually.explain them that requirements indexed after the baseline will be shown as slightly different.

How to change the mode?

Switching is manual. The option is available in the Confluence administration → Requirement Yogi → Options → section "Indexing" → Change mode.

...