Requirement Yogi
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata


What is the pricing for the Data Center version?

The pricing is exactly 25% of Confluence for each tier, except the lower tiers where it is the price of the Server version. At the time of writing:

TierConfluence DCRequirement Yogi DC
500$12,000$4,850
1000$24,000$6,000
2000$48,000$12,000
3000$72,000$18,000
... etc. The latest price information can be found on our product page. 

What is our progress on Data Center compatibility?

ConfluenceJira

Progress : DONE!

Approved on August 7th, 2019.

Progress: 100%

Approved in 2019.

What is our version support policy?

We follow Atlassian's Long Term Support release policy: We support those versions for 2 years.

ProductVersionFirst publishedSupported until
Jira Software7.616/11/201716/11/2019
Jira Software7.1328/11/201828/11/2020
Jira Software8.521/10/201921/10/2021
Jira Software8.1308/10/202008/10/2022
...


Confluence6.612/12/201712/12/2019
Confluence6.1304/12/201804/12/2020
Confluence7.421/04/202021/04/2022
...


What is our escalation process?

See Data Center SLA / Escalation process.

What is our detailed progress?

We've given performance information on the page Performance.

RequirementProgress
Work on cluster

(tick) Yes for Confluence.

(tick) Yes for Jira.

Testing performance with thousands of records.

(tick) We've tested the performance in the browser for 1000 pages of 300 requirements each and it performs well. Administrators can use the Global limit to limit the number of requirements that can be managed in a single document.

(tick) We've tested the performance on the server for 1500 pages of 500 requirements each. It performs well. We keep this information in the page named Performance.

Testing performance with millions of records, on an AWS deployment.

(tick) We've tested with 1 million pages (with or without requirements) and 1 million requirements.

Solving performance bottlenecks.

(tick) All Confluence bottlenecks have been solved, notably the global limit, which was implemented a few months ago.

(tick) The Jira implementation was entirely changed to support a queue.

(warning) We have noticed our upgrade tasks and REST resources use a single Hibernate session despite the "flush session" instruction that we perform at each saving point. There is no way around this.

Submitting results to Atlassian to get the DC certification.

(tick) Success, for Confluence, PSEA and Jira.

(minus) The "Test & Compliance" module will not have a "Data Center" version. This module is not generally used by Data Center customers.

Provide a clear escalation process for customers.See our escalation process.

Performance issues we've identified

No impact on pages which don't use Requirement Yogi

Our app has very little impact on pages or issues without Requirement Yogi (It only performs 1 SQL query per page load, 1 SQL query per issue in Jira).

IssueOur plans
(tick) A customer tried to create 1500 requirements on a single page, and the editor is slow.

This is not due to Requirement Yogi.

If one creates a Confluence page with a table of 1500 lines containing "Status" macros, which are native to Confluence, then they get the same performance.

(tick) The search screens (traceability matrix, dependency matrix, etc) require resources to build.
  • There is a Global limit for global administrators to control how many requirements can be viewed at once. This was introduced in: RY-311 - Getting issue details... STATUS .
  • We've already implemented pagination for those screens.
  • There will be no caching for those matrixes, as users expect to see updated information.
  • Those screens may take resources to build, but this is proportional to the quantity of data that you need. There is no way around gathering that much data, if that's what your users need.
(warning) Large hibernate sessions: We've noticed that Confluence doesn't respect our instructions to flush the transactions when we order them.
  • It doesn't have a large impact yet because we don't have large upgrade tasks.
  • When we have upgrade tasks, we will transform them into jobs which operate on a subset of items at a time.

* A "Requirement" is a line in the table of a requirement document.

  • No labels