Guía de implementación › Ejemplos de casos prácticos › Ejemplos de escritura de lógica de negocios vigente › Caso práctico 15: Métricas en clúster

Caso práctico 15: Métricas en clúster

Normalmente, cuando se describe un trozo determinado de software, esta descripción se puede dividir en dos partes: el QUÉ y el CÓMO. Con el QUÉ queremos hacer referencia a la descripción de lo que hace ese trozo de código. El CÓMO es cómo lo hace. Hay una tendencia a concentrarse en el QUÉ e ignorar parte del CÓMO. El motivo es sencillo y, en muchos casos, está justificado. Con ello, se reduce el acoplamiento entre los componentes y no hay que preocuparse con información que muchas veces es irrelevante. Sin embargo, en muchos casos, el coste de ignorar el CÓMO supone un mal rendimiento.

Este caso práctico trata la forma en la que el motor está calculando métricas en clúster (la respuesta a la parte del CÓMO) y describe el coste de rendimiento que implican determinadas implementaciones. También trata las diversas formas de reducir este coste mediante el cambio de la implementación.

¿Qué son las métricas en clúster?

Las métricas en clúster son métricas que incluyen en su definición un determinado grupo de recursos. Este grupo se conoce como el clúster de la métrica y cada uno de los recursos de ese grupo se conoce como un elemento de clúster. Al calcular una métrica en clúster, se realiza un cálculo separado para cada uno de esos elementos de clúster. Los cálculos para cada uno de esos elementos de clúster son similares entre ellos, excepto:

• Context.ClusterItem: el valor de la propiedad Context.ClusterItem que es igual al elemento de clúster que se está calculando.
• Registrations by Cluster item: cuando una métrica se registra en los eventos por elemento de clúster, cada elemento de clúster recibe eventos de datos sin procesar brutos y eventos de reutilización que se envían a este elemento de clúster.

¿Cómo se calculan las métricas en clúster?

Lo más importante que hay que entender sobre el cálculo de una métrica en clúster es que todos los elementos de clúster se calculan en paralelo. Por paralelo no se quiere decir que se calculan por distintos subprocesos, sino que mientras se procesan los distintos eventos que los elementos de clúster deben manejar, los eventos se están procesando de forma secuencial y para cada evento los elementos de clúster relevantes se convocan y procesan este evento. Por ejemplo, hay muchos eventos que deberían tratar varios elementos de clúster. Hay dos formas de hacerlo:

Ejemplo: Opción 1

Para cada elemento de clúster C
     Para cada evento E que C debería manejar
          Dejar que C maneje a E

Ejemplo: Opción 2

Para cada evento E
     Para cada elemento de clúster C que maneja a E
          Dejar que C maneje a E

El motor maneja métricas en clúster mediante la Opción 2.

Otro punto importante que hay que entender es que un componente llamado Script Control realiza la ejecución de VBScript dentro de PslWriter. Hay solamente una sola instancia de este componente por cada métrica y esta instancia se reutiliza para el cálculo de los diversos elementos de clúster. Como los elementos de clúster se calculan paralelamente, como se ha mencionado antes, y el componente Script Control puede contener solamente los datos de un solo elemento de clúster en cada momento, tenemos que cambiar frecuentemente los datos dentro del componente Script Control.

Para explicar esto, se presenta a continuación un código falso más detallado que realiza el cálculo.

1-     Para cada métrica M
2-          Permitir que X sea el primer evento que no se maneja todavía por M
3-          Permitir que T sea la marca de tiempo del último estado antes de X
4-          Permitir que L sea la lista de todos los eventos registrados por M (todos los elementos de clúster) empezando por la marca de tiempo T hasta la hora actual
5-          Para cada evento E en L
6-               Para cada elemento de clúster C que maneja a E
7-                    Permitir que C sea el elemento de clúster que está cargado actualmente en Script Control
8-                    Tomar los valores de las variables globales de Script Control y almacénelas aparte para C
9-                    Tomar los valores de las variables globales guardadas aparte para C y cárguelos en Script Control
10-                    Manejar evento E

Este proceso completo de encontrar algo de tiempo de un evento que todavía no se ha tenido cuenta y realizar, a continuación, el cálculo a partir de ese punto se llama recálculo. El proceso de sustituir los valores de las variables globales (pasos 8 y 9 en el código anterior) se llama conmutación de contexto.

Los dos problemas principales que se pueden ver fácilmente en el código anterior son:

• El recálculo se hace para todos los elementos de clúster juntos. A partir del momento en el que el tiempo T (paso 3 en el código anterior) se encuentra una vez, todos los elementos de clúster realizan un recálculo basándose en ese punto. Esto significa que siempre que un solo elemento de clúster tenga algún nuevo evento, todos los elementos de clúster se recalculan.
• La conmutación de contexto se realiza muy a menudo. Esto se puede ver fácilmente, ya que la conmutación de contexto (pasos 8 y 9 en el código anterior) se encuentra dentro del bucle interior.

Recálculo de métricas en clúster

• Descripción del problema

  Como ya se ha explicado, todos los elementos de clúster en una métrica en clúster se recalculan en conjunto. Esto significa que si tenemos una métrica agrupada en más de 1000 elementos de clúster y uno de ellos necesita un recálculo del último año, debido a algún nuevo evento que ha llegado, todos los 1000 elementos de clúster deben recalcularse para el último año.

• Posibles soluciones

  Las siguientes sugerencias de soluciones pueden reducir las consecuencias de este problema, pero no son siempre aplicables y cada una tiene sus propias desventajas. Lo más importante es entender el problema y su coste estimado y comparar este coste con el coste de la solución propuesta.

  • Cuando el número de elementos de clúster es pequeño, podemos considerar la opción de definir cada uno de ellos como una métrica separada. La desventaja de este enfoque es, por supuesto, el coste de mantenimiento de varias métricas, así como el hecho de que no podemos realizar un informe de la métrica completa y, a continuación, entrar en más detalle en un elemento de clúster específico
  • Cuando el número de elementos de clúster es grande pero solamente uno (o unos pocos) de ellos se recalcula frecuentemente, podemos considerar el hecho de poner este elemento de clúster en una métrica aparte y dejar todos los demás elementos de clúster en la otra métrica
  • Utilice con frecuencia un cálculo fijo para el contrato/métrica relevante para que esta métrica nunca tenga recálculos largos.
  • Realice algunos cambios en los adaptadores y los orígenes de datos para que no haya recálculos largos (es decir, no envíe eventos cuya marca de tiempo sea anterior a un mes)

Conmutación de contexto

• Descripción del problema

  Como ya se ha explicado, la conmutación de contexto se hace en el bucle más interior. Dicho de otra manera, para cada evento que debería manipularse por cada elemento de clúster. Cuando una métrica recibe muchos eventos y cuando cada evento se manipula por muchos elementos de clúster, esta cantidad puede ser muy alta. Hay que añadir que la operación de conmutación de contexto es relativamente cara (en relación a la manipulación del propio evento en la lógica de negocios), con lo que tendríamos un problema.

  El coste de la operación de conmutación de contexto es proporcional al tamaño de los datos que se "cambian". Los datos que cambiamos durante la conmutación de contexto son los valores de todas las variables globales en nuestra lógica de negocios (también llamada "el estado"). De esta forma, mientras más variables globales se tenga y mayor sea el tamaño de esas variables globales, más cara será la operación de conmutación de contexto.

  En particular, no se recomienda utilizar las asignaciones de lógica de negocios en métricas en clúster, sobre todo si el tamaño de esas asignaciones puede ser grande.

• Posibles soluciones
  • Reducción del tiempo de cada una de las conmutaciones de contexto

    La idea es reducir el tamaño del estado (variables globales). Este enfoque se puede hacer reescribiendo la lógica de negocios para que no contenga asignaciones. Por supuesto esto no es siempre posible, pero cuando sí lo es, se recomienda.

  • Reducción de la cantidad de los conmutadores de contexto

    Cuando el clúster es pequeño es posible crear una métrica separada para cada elemento de clúster.

    Evite métricas en clúster con muchos elementos agrupados en clúster que se registran a los mismos eventos. La idea aquí es la siguiente:

    Si cada evento está manejado por un solo elemento de clúster, la cantidad de la conmutación de contexto es proporcional al número de eventos

    Si cada evento está manejado por todos los elementos de clúster, la cantidad de la conmutación de contexto es proporcional al número de eventos por el número de elementos de clúster.

    Cree una métrica que no esté agrupada en clúster que calcule los resultados de todos los elementos de clúster original (que son ahora recursos sencillos y no elementos de clúster). Haga que esta métrica envíe el resultado de cada uno de los elementos de clúster como un evento. Cree otra métrica que esté agrupada en clúster y que reciba los eventos de la primera métrica e informe del valor recibido en esos eventos como resultado. La idea aquí es que una métrica que no esté agrupada en clúster manejará la gran cantidad de eventos de datos sin procesar y que la métrica en clúster manejará un solo evento por período por elemento de clúster.