Guida all'implementazione › Esempi di case study › Esempi di scrittura di business logic efficace › Case study 15: metriche di gruppo

Case study 15: metriche di gruppo

In genere, nella descrizione di un determinato componente software, questa può essere divisa in due parti, WHAT e HOW. Per WHAT si intende la descrizione del significato di questa parte di codice. Per HOW si intende la procedura eseguita. Esiste una tendenza a concentrarsi sulla parte WHAT, trascurando la parte HOW. Il motivo di ciò è semplice e in molti casi giustificato. In questo modo, è possibile ridurre l'accoppiamento tra i componenti ed evitare di tediare l'utente con informazioni in molti casi non pertinenti. In molti casi, tuttavia, il costo di trascurare la parte HOW si traduce in scarse prestazioni.

Il presente case study descrive il modo in cui il motore calcola le metriche di gruppo (risposta alla parte HOW) e descrive il costo delle prestazioni implicate in determinate implementazioni. Inoltre, vengono descritti diversi metodi per ridurre questo costo modificando l'implementazione.

Che cosa sono le metriche di gruppo

Le metriche di gruppo sono metriche che comprendono nella propria definizione un certo gruppo di risorse. Questo gruppo è indicato come Gruppo di metrica e ogni risorse in tale gruppo è definito come elemento di gruppo. Durante il calcolo di una metrica di gruppo viene eseguito un calcolo distinto per ciascun elemento di gruppo. I calcoli per ciascun elemento di gruppo sono simili l'uno all'altro, ad eccezione di:

• Context.ClusterItem: valore della proprietà Context.ClusterItem che è uguale all'elemento di gruppo in corso di calcolo.
• Registrazioni per elemento di gruppo: quando una metrica è registrata a eventi per elemento di gruppo, ciascun elemento di gruppo riceve dati non elaborati ed eventi di riusabilità che vengono inviati a questo elemento di gruppo.

Procedura di calcolo delle metriche di gruppo

L'aspetto più importante da comprendere sul calcolo di una metrica di gruppo è che tutti gli elementi di gruppo vengono calcolati in parallelo. Per parallelo non significa che vengono calcolati con thread diversi, ma che durante l'elaborazione dei vari eventi che devono essere gestiti dai vari elementi di gruppo, gli eventi vengono elaborati in sequenza e per ciascun evento vengono chiamati gli elementi di gruppo pertinenti che elaborano l'evento. Ad esempio, sono presenti molti eventi che devono essere gestiti da numerosi elementi di gruppo. Esistono due modi per tale scopo:

Esempio: Opzione 1

Per ciascun elemento di gruppo C
     Per ogni evento E che deve essere gestito da C
          Consentire a C di gestire E

Esempio: Opzione 2

Per ogni evento E
     Per ciascun elemento di gruppo C che deve gestire E
          Consentire a C di gestire E

Il motore gestisce le metriche di gruppo utilizzando l'opzione 2.

Un altro punto importante da comprendere è che l'esecuzione di VBScript in PslWriter viene effettuata da un componente denominato Script Control. È presente solo una singola istanza di questo componente per ogni metrica e tale istanza viene riutilizzata per il calcolo dei vari elementi di gruppo. Poiché gli elementi di gruppo vengono calcolati in parallelo come descritto in precedenza, e poiché il componente Script Control può contenere solo i dati di un singolo elemento di gruppo in ogni momento, è necessario commutare i dati di frequente all'interno del componente Script Control.

A scopo illustrativo, viene riportato di seguito uno pseudo-codice più dettagliato per l'esecuzione del calcolo.

1-     For each metric M
2-          Let X be the earliest event not yet handled by M
3-          Let T be the timestamp of the latest state before X
4-          Let L be the list of all events registered by M (all cluster items) starting from timestamp T until the current time
5-          For each event E in L
6-               For each cluster item C that should handle E
7-                    Let C’ be the cluster item that is currently loaded into the script control
8-                    Take the values of the global variables from the script control and store them aside for C’
9-                    Take the values of the global variables stored aside for C and load them into the script control
10-                    Handle event E

L'intero processo di rilevamento talvolta di un evento non ancora preso in considerazione e di esecuzione del calcolo da questo punto in poi è denominato Nuovo calcolo. Il processo di sostituzione dei valori delle variabili globali (i passaggi 8 e 9 nel codice sopra riportato) è denominato Cambio di contesto.

I due principali problemi che possano essere facilmente riscontrati nel codice riportato sopra sono:

• Il nuovo calcolo viene eseguito per tutti gli elementi di gruppo insieme. Poiché il punto nel tempo T (passaggio 3 nel codice sopra riportato) è rilevato una sola volta e quindi tutti gli elementi di gruppo eseguono il nuovo calcolo in base a quel momento. Ciò significa che, quando un singolo elemento di gruppo contiene un nuovo evento, tutti gli elementi di gruppo vengono ricalcolati.
• Il cambio di contesto viene eseguito molto spesso. Questo può essere facilmente riscontrato poiché il cambio di contesto (passaggi 8 e 9 nel codice sopra riportato) avviene nel ciclo interno.

Ricalcolo delle metriche di gruppo

• Descrizione del problema

  Come già indicato, tutti gli elementi di gruppo in una metrica di gruppo vengono ricalcolati come un insieme. Questo significa che se si dispone di una metrica di gruppo con 1000 elementi di gruppo e per uno di essi è necessario il ricalcolo dell'ultimo anno a causa di qualche nuovo evento ricevuto, tutti i 1000 elementi di gruppo vengono ricalcolati per l'ultimo anno.

• Soluzioni possibili

  Le soluzioni suggerite di seguito possono ridurre le conseguenze del problema, ma non sono sempre applicabili e ognuna presenta i propri svantaggi. L'aspetto più importante è comprendere il problema e il costo stimato e confrontare tale costo con il costo delle soluzioni proposte.

  • Quando il numero degli elementi di gruppo è piccolo, è possibile prendere in considerazione la definizione di ognuno di essi come una metrica distinta. Il lato negativo di questo approccio è, ovviamente, il costo di manutenzione per la gestione di diverse metriche, nonché il fatto che non è possibile eseguire un report per l'intera metrica e quindi eseguire il drill-down in un elemento di gruppo specifico
  • Quando il numero degli elementi di gruppo è elevato, ma solo uno o un numero ridotto di essi viene ricalcolato di frequente, è possibile considerare di inserire questo elemento di gruppo in una metrica separata e lasciare tutti gli altri elementi di gruppo nell'altra metrica
  • Utilizzare di frequente il blocco del calcolo per il contratto o la metrica pertinente, in modo che questa metrica non sia mai sottoposta a ricalcoli lunghi
  • Eseguire alcune modifiche negli adapter e nelle origini dati, in modo che non vi siano ricalcoli lunghi (ad esempio, non inviare eventi il cui valore di data/ora è antecedente di un mese)

Cambio di contesto

• Descrizione del problema

  Come già indicato, il cambio di contesto viene eseguito nel ciclo interno. In altre parole, per ogni evento che deve essere gestito da ciascun elemento di gruppo. Quando una metrica riceve molti eventi e ogni evento è gestito da molti elementi di gruppo, questa quantità può essere molto elevata. Inoltre, l'operazione di cambio di contesto è relativamente costosa (rispetto alla gestione dell'evento in sé nella business logic) e si presenta un problema.

  Il costo dell'operazione di cambio di contesto è proporzionale alle dimensioni dei dati commutati. I dati commutati durante il cambio di contesto sono i valori di tutte le variabili globali nella business logic (denominata anche "stato"). Pertanto, quanto maggiori sono il numero di variabili globali di cui si dispone e le dimensioni di tali variabili globali, tanto più costosa è l'operazione di cambio del contesto.

  In particolare, non è consigliabile utilizzare le mappe di business logic nelle metriche di gruppo, soprattutto se le dimensioni delle mappe possono essere grandi.

• Soluzioni possibili
  • Ridurre il tempo di ciascun cambio di contesto

    L'idea è di ridurre le dimensioni dello stato (variabili globali). È possibile eseguire questo approccio con la riscrittura della business logic, in modo che non contenga mappe. Ovviamente non è sempre possibile, ma qualora lo fosse, è consigliabile.

  • Ridurre la quantità di cambi di contesto

    Se il gruppo è piccolo, è possibile creare una metrica separata per ogni elemento di gruppo.

    Evitare le metriche di gruppo con molti elementi di gruppo che registrano gli stessi eventi. L'idea in questo caso è la seguente:

    Se ciascun evento è gestito da un unico elemento di gruppo, la quantità di cambi di contesto è proporzionale al numero di eventi

    Se ciascun evento è gestito da tutti gli elementi di gruppo, la quantità di cambi di contesto è proporzionale al numero di eventi per il numero di elementi di gruppo

    Creare una metrica non di gruppo in grado di calcolare i risultati per tutti gli elementi di gruppo originari (che a questo punto sono semplici risorse e non elementi di gruppo). Fare in modo che la metrica invii il risultato di ogni elemento di gruppo come un evento. Creare un'altra metrica che sia di gruppo e che riceva gli eventi dalla prima metrica e generi un report sul valore ricevuto in tali eventi come risultato. L'idea in questo caso è che le grandi quantità di eventi di dati non elaborati verranno gestite da una metrica non di gruppo e che la metrica di gruppo gestirà un evento singolo per periodo per elemento di gruppo.