Data Center strategy for Requirement Yogi

We will track on this page everything related to Data Center

This page has been updated regularly, our RY products have passed the DC approval, the Confluence part is published and the Jira and PSEA parts will be published in a few days.

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:

Tier	Confluence DC	Requirement Yogi DC
500	$12,000	$4,850
1000	$24,000	$6,000
2000	$48,000	$12,000
3000	$72,000	$18,000
... etc.

What is our progress on Data Center compatibility?

Confluence	Jira
Progress : DONE! Our application was approved on August 7th, 2019.	Progress: 95% The version has been submitted to Atlassian and will be published in the next few days. We already have obtained approval from Atlassian. We have published the release notes: Release notes 2.2.5 for Jira.

What is our version support policy?

We follow the Atlassian Enterprise release policy: We support those versions for 2 years.

Product	Version	First published	Supported until
Jira	7.6	16/11/2017	16/11/2019
Jira	7.13	28/11/2018	28/11/2020
Confluence	6.6	12/12/2017	12/12/2019
Confluence	6.13	04/12/2018	04/12/2020

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.

Requirement	Progress
Work on cluster	Yes for Confluence. Yes for Jira.
Testing performance with thousands of records.	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. 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.	We've tested with 1 million pages (with or without requirements) and 1 million requirements.
Solving performance bottlenecks.	All Confluence bottlenecks have been solved, notably the global limit, which was implemented a few months ago. The Jira queue is the current bottleneck we are trying to solve. It requires a new implementation of the "Remote issue links" in Jira. 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.
Submitting results to Atlassian to get the DC certification.	Success, for Confluence, PSEA and Jira. Published for Confluence The PSEA and Jira modules are approved and uploaded to the Marketplace, and pending manual action on the Atlassian, which they generally do in very few days. 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).

Issue

Our plans

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.

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.

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.

Space shortcuts

Page tree