Choosing the indexing engine
In the release 3.5, we have introduced the back-end indexing. How should an administrator choose between the two indexing engines?
What is the recommended setting?
Engine Version 2 - Using the queue - is the only recommended setting for Data Center instances. It weighs less on the performance of Confluence.
What is the indexing engine?
When a user enters requirements on a page and saves it, the indexing engine extracts requirements from text, tables and layouts, and put it in a database.
What is the engine Version 1, “Legacy JS”?
Up until version 3.4, requirements would be extracted while they were displayed for the first time. It would produce 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.
What is the engine Version 2, "Using the queue"?
When a page is saved and the new mode is selected, we don't process it immediately. Rather, we put it in a queue (The same mechanism we are already using to send events to Jira) and we process it whenever Confluence is available.
It means saving the page is much faster,
It also means we had to rewrite the indexing engine and, this time, we've correctly supported bullet-point lists, tables, images, etc.
Of course, since this is a new engine, it may happen that we've missed some text formatting, so please give us feedback if you see any text format that you would like to be supported.
Why did it have to change?
Atlassian's Data Center line of products aims for enterprise-level quality. Mostly, instant performance while saving the page was an issue for the user experience, and we needed the users to be able to instantly save the page and view it. Secondly, dealing with HTML is difficult and often introduces whitespaces changes even when the original text hasn't changed. Using the new indexing will result in much more deterministic outputs.
Is there an impact to changing modes?
YES. We don't recommend switching modes back-and-forth while creating baselines. When users create baselines, they create a snapshot of the requirements at a given time. If an administrator switches the mode, then requirements created in the next baseline will not be comparable with requirements in the previous baseline.
No performance impact. The new mode is more lightweight on instances, since we put 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.
Should an existing customer switch to the new mode?
New customers should be on the new mode. Should existing customers switch?
YES, existing customers should use the new mode, for the performance.
BUT check whether your users rely on 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.
How to change the mode?
The option is available in the Confluence administration → Requirement Yogi → Options → section "Indexing" → Change mode.
See at the top of this page for the screenshot.
Did we answer all your questions?
Feel free to ask questions on Requirement Yogi support.