Author: Victor Boctor

The Mantis database contains a snapshot of the information at a point in time, hence, the reports on it can only do the same. As far as project management is concerned, it is often needed to track changes over time. For example, how is the number of bugs opened per day and bugs resolved per day vary as the project gets closer to the release date?

This can be done by savings metrics at certain times and then reporting at this metrics. These metrics are called performance counters, and they can be calculated as often as necessary. By default, counters will be calculated daily.

• mantis_perf_counters_def_table
  • id
  • name = string (64)
  • description = string (255)
  • function = Name of function to call to calculate the value (this is prefixed by perf_counter_calc_*).
  • params = string (255) - format is typically as follows: project_id=2,user_id=0,field3=value3
  • frequency = frequency in hours (e.g. 24 for performance counters that should be calculated daily).
  • enabled = boolean
  • next_calc_due - datetime - the timestamp when the next calculation is due.
  • date_created - datetime
  • last_updated - datetime

• mantis_perf_counters_val_table
  • id
  • perf_counter_def_id
  • timestamp - timestamp where the counter was calculated
  • value (int)

A script will be added that will calculate all the enabled performance counters that are due to calculation. The algorithm should be as follows:

for each enabled counter that is due for calculation
      calculate the performance counter and record the value.
      update the next_calc_due on the counter definition. 

• performance_counters_manage_threshold - add/delete

• Add counters: This can be done through the web interface as long as the function that calculates them is available.
• Modify counters: We shouldn't really be able to change the parameters sent to the counter calculator. If done then we need to delete all historical values. Hence, delete/add will be used.
• Delete counters: Deletes the counter definition as well as all historical values.
• Enable/Disable Counters

• Number of issues
  • status (optional) (e.g. value|value|value)
  • priority (optional) (e.g. value|value|value)
  • severity (optional) (e.g. value|value|value)
  • category (optional)
• Number of opened issues since last calculation based on date_submitted
  • priority (same as above)
  • severity (same as above)
  • category (save as above)
• Number of resolved issues
  • This can be done using tokens. A token can be used to store the last value. The number resolved = total number in previous run - total run in current run + total number reported.

A company wants to keep a performance counter for the number of issues that has priority 1 and have been open for more than 3 days. This counter is to be called “sla_slips”.

function perf_counter_calc_sla_slips( $p_params ) {
    $t_priority = $p_params['priority'];   // will be set to 1
    $t_days = $p_params['days'];  // will be set to 3
 
    // calculate the number here and store in $t_counter.
 
    return $t_counter;
}

• Are we going to provide a generic interface to view counters?
• If so,
  • it should be possible to graph multiple counters in the same graph.
  • we should add a view access level to the definition table.
• The other option is to store this information in the database and have the access control implemented in the reports that access the performance counters.
• Ability to use saved filters to calculate values for counters. For example, number of issues matching a filter would be the value of the counter.
• Template Counters - it would be very useful to have a counter that counts the number of open issues for a developer or a category, then be able to run this counter for every developer or every category, rather than having to define a counter record per developer or per category.

I don't understand the original premise, that Mantis only has a snapshot of information as at the current time. It already contain hsitorical data with fields storing when a task was submitted, etc. So the example above “number of issues that has priority 1 and have been open for more than 3 days” is already trivial. SELECT * from bug WHERE date_submitted > now() - 3 AND priority = 1

In projects I've worked on, de-normalising the database in this way has often created a lot more work in the long term than just building more advanced queries. If there is historical information which is lost over time, then perhaps an extra table to keep that information in a revisioned format would be a better option. But from what I've seen so far of Mantis, this appears to not be a problem. — aristedes 2007/04/14 04:04