History - Administrator's guide
The History feature was introduced in Requirement Yogi 4.4.0.
Here is a little more data to understand the impact of activating this feature.
CPU performance
We haven’t seen an impact in our performance tests. However, it seems obvious that saving history is extra work, and it could be a burden if your Confluence server is already at its max usage. Please only enable the history if you monitor your Confluence instance and database server for CPU and memory usage.
Evaluating storage requirements
Since we’re saving entire requirements at every change, it may seem a lot of data. However, we’ve found through theoretical calculations that this data isn’t overwhelming.
We’ll take the example of a company with 100k requirements with 1 KB of text. Users save 500 pages per day after modifying 10 requirements. The example requirement looks like this:
We’ll assume the text is formatted, so 1 KB of text is 3063 bytes of HTML. It is written in JSON and the description of the requirement is also the first property, so the text is doubled. Add escaping, and each row of history is 6534 bytes.
The database size before the history is, therefore, 100k requirements x 6534 bytes = 653 MB (it’s an order of magnitude, not a close approximation),
Since users modify 10 requirements in 500 pages per day, it creates 5000 history records per day,
Users work 5 days per week, 44 weeks per year, so 5000 records x 5 days x 44 weeks x 6534 bytes per record = 7GB of history data for one year of archives.
This example represents the worst conditions: Most requirements are smaller, most BAs don’t work on requirements every day, most companies have a few hundreds, and not a hundred thousands requirements, etc. If we take more reasonable estimates, a company with 10k requirements would have 70MB of data and 700MB of history.
Our recommendation
Please perform your own evaluation of your storage needs, or proceed experimentally by progressively increasing the duration.
Technical details
How it works: When a requirement is modified, we take an entire snapshot of the JSON of the record. This happens even if only one property was modified. In case the software missed an event or a type of events, it has no impact, since we’re not recording the differences, we’re only extracting the full view, every time.
Technically, after each change, a History job is created in the queue for each requirement modified. It’s a deferred job, so, after a few seconds, it executes and attempts to create a history record. If the record is the same as the previous one, the entry is not created. For a page with 50 requirements, 50 jobs are created, but only requirements which have been modified will create an entry in the history table.