Differences

This shows you the differences between two versions of the page.

--- mantisbt:performance_counters_requirements [2006/09/28 02:30] – created vboctor
+++ mantisbt:performance_counters_requirements [2011/11/16 07:38] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
@@ Line 12: / Line 12: @@
    * mantis_perf_counters_def_table
-     * perf_counter_def_id
+     * 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
-     * perf_counter_val_id
+     * id
      * perf_counter_def_id
-     * timestamp
+     * timestamp - timestamp where the counter was calculated
-     * value (int) or double?
+     * value (int)
 ===== Cronjob Script =====
@@ Line 30: / Line 34: @@
 <code>
-for each enabled counter
+for each enabled counter that is due for calculation
-   if no previous recorded values or last recorded greater than "frequency" hours then
       calculate the performance counter and record the value.
+      update the next_calc_due on the counter definition.
 </code>
@@ Line 44: / Line 48: @@
      * 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
+===== Out-of-the-box-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.
+===== New Performance Calculation Functions =====
+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".
+<code php>
+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;
+}
+</code>
 ===== Brainstorming =====
@@ Line 52: / Line 86: @@
        * 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.
 ===== Feedback =====
-Put your feedback in this section.
+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//