Compartir a través de

Mejores prácticas de persistencia

En este documento se tratan los procedimientos recomendados para el diseño y la configuración del flujo de trabajo relacionados con la persistencia del flujo de trabajo.

Diseño e implementación de flujos de trabajo duraderos

En general, los flujos de trabajo realizan trabajo en períodos cortos que se intercalan con horas durante las que el flujo de trabajo está inactivo porque está esperando un evento. Este evento puede ser como un mensaje o un temporizador de expiración. Para poder descargar la instancia de flujo de trabajo cuando está inactiva, el host de servicio debe conservar la instancia de flujo de trabajo. Esto solo es posible si la instancia de flujo de trabajo no está en una zona sin persistencia (por ejemplo, esperando a que se complete una transacción o esperando una llamada de retorno asincrónica). Para permitir que una instancia de flujo de trabajo inactiva se descargue, el autor del flujo de trabajo debe usar ámbitos de transacción y actividades asincrónicas solo para acciones de corta duración. En particular, el autor debería mantener lo más breves posible las actividades de retraso dentro de estas zonas sin persistencia.

Un flujo de trabajo solo se puede conservar si todos los tipos de datos usados por el flujo de trabajo son serializables. Además, los tipos personalizados usados en los flujos de trabajo persistentes deben ser serializables con NetDataContractSerializer para que sean guardados por SqlWorkflowInstanceStore.

Una instancia de flujo de trabajo no se puede recuperar en caso de un error de host o equipo si no se ha conservado. En general, se recomienda conservar una instancia de flujo de trabajo al principio del ciclo de vida del flujo de trabajo.

Si su flujo de trabajo está ocupado durante mucho tiempo, le recomendamos conservar la instancia de flujo de trabajo con regularidad a lo largo de su período ocupación. Para ello, agregue Persist actividades a lo largo de la secuencia de actividades que mantienen ocupada la instancia de flujo de trabajo. De esta manera, reciclando el dominio de la aplicación, los errores del host o del equipo no hacen que el sistema revierta hasta el inicio del período de ocupación. Tenga en cuenta que agregar Persist actividades al flujo de trabajo podría provocar una degradación del rendimiento.

Windows Server App Fabric simplifica considerablemente la configuración y el uso de la persistencia. Para obtener más información, consulte Windows Server App Fabric Persistence.

Configuración de parámetros de escalabilidad

Los requisitos de escalabilidad y rendimiento determinan la configuración de los parámetros siguientes:

Estos parámetros deben establecerse de la siguiente manera, según el escenario actual.

Escenario: un pequeño número de instancias de flujo de trabajo que requieren un tiempo de respuesta óptimo

En este escenario, todas las instancias de flujo de trabajo deben permanecer cargadas cuando se vuelven inactivas. Establezca TimeToUnload en un valor grande. El uso de esta configuración impide que una instancia de flujo de trabajo se mueva entre equipos. Use esta configuración solo si se cumple una o varias de las siguientes opciones:

  • Una instancia de flujo de trabajo recibe un único mensaje durante toda su duración.

  • Todas las instancias de flujo de trabajo se ejecutan en un único equipo

  • El mismo equipo recibe todos los mensajes recibidos por una instancia de flujo de trabajo.

Utilice las actividades Persist o establezca TimeToPersist en 0 para habilitar la recuperación de su instancia de flujo de trabajo después de errores en el host de servicio o en el equipo.

Escenario: Las instancias de flujo de trabajo están inactivas durante largos períodos de tiempo

En este escenario, establezca TimeToUnload en 0 para liberar los recursos lo antes posible.

Escenario: las instancias de flujo de trabajo reciben varios mensajes en un breve período de tiempo

En este caso, establezca TimeToUnload en 60 segundos si el mismo equipo recibe estos mensajes. Esto evita una secuencia rápida de descarga y carga de una instancia de flujo de trabajo. Esto tampoco mantiene la instancia en memoria durante demasiado tiempo.

Configure TimeToUnload a 0 y configure InstanceLockedExceptionAction a BasicRetry o AggressiveRetry si estos mensajes pueden ser recibidos por equipos diferentes. Esto permite que otro equipo cargue la instancia de flujo de trabajo.

Escenario: el flujo de trabajo usa actividades de retraso con duraciones cortas

En este escenario, SqlWorkflowInstanceStore sondea regularmente la base de datos de persistencia buscando las instancias que se deberían cargar por una actividad Delay expirada. Si SqlWorkflowInstanceStore encuentra un temporizador que vaya a expirar durante el próximo intervalo de sondeo, el Almacén de instancias de flujo de trabajo de SQL acorta el intervalo de sondeo. A continuación, el siguiente sondeo se producirá justo después de que el temporizador haya expirado. De esta manera, el el Almacén de instancias de flujo de trabajo de SQL logra una gran exactitud de temporizadores que se ejecutan durante más tiempo que el intervalo de sondeo, que es establecida por RunnableInstancesDetectionPeriod. Para habilitar el procesamiento oportuno de retrasos más cortos, la instancia de flujo de trabajo debe permanecer en memoria durante al menos un intervalo de sondeo.

Establezca TimeToPersist en 0 para escribir la hora de expiración en la base de datos de persistencia.

Establézcalo TimeToUnload en mayor o igual que RunnableInstancesDetectionPeriod para mantener la instancia en memoria durante al menos un intervalo de sondeo.

No se recomienda reducir RunnableInstancesDetectionPeriod porque esto provoca un aumento de la carga en la base de datos de persistencia. Cada host de servicio que usa el SqlWorkflowInstanceStore consulta la base de datos una vez por período de detección. Establecer RunnableInstancesDetectionPeriod en un intervalo de tiempo demasiado pequeño puede hacer que el rendimiento del sistema disminuya si el número de hosts de servicio es grande.

Configuración del almacén de instancias de flujo de trabajo de SQL

El almacén de instancias de flujo de trabajo de SQL tiene los siguientes parámetros de configuración:

InstanceEncodingOption
Este parámetro indica a que SqlWorkflowInstanceStore comprima el estado de la instancia del flujo de trabajo. La compresión reduce la cantidad de datos almacenados en la base de datos de persistencia y reduce el tráfico de red en caso de que la base de datos de persistencia resida en un servidor de bases de datos dedicado. Si se usa la compresión, requiere recursos computacionales para comprimir y extraer el estado de la instancia. En la mayoría de los casos, la compresión produce un mayor rendimiento.

InstanceCompletionAction
Este parámetro indica a que SqlWorkflowInstanceStore mantenga o elimine instancias completadas. Mantener las instancias completadas aumenta los requisitos de almacenamiento de la base de datos de persistencia y conduce a tablas más grandes, lo que aumenta los tiempos de búsqueda de tablas. A menos que se requieran instancias completadas para depurar o auditar, es mejor indicar a SqlWorkflowInstanceStore que elimine las instancias completadas. Las instancias eliminadas solo deben mantenerse si el usuario establece un proceso para eliminarlas finalmente. Tenga en cuenta que las claves de correlación no se pueden reutilizar siempre y cuando la instancia de flujo de trabajo completada resida en el almacén de instancias.

RunnableInstancesDetectionPeriod
Este parámetro define el intervalo máximo con el que sondea la SqlWorkflowInstanceStore base de datos de persistencia para las instancias que se deben cargar cuando expira una Delay actividad. SqlWorkflowInstanceStore Si encuentra un temporizador que expirará en el siguiente intervalo de sondeo, acorta el intervalo de sondeo para que el próximo sondeo se produzca justo después de que el temporizador haya expirado. De esta manera, el Almacén de instancias de flujo de trabajo de SQL logra una gran exactitud de los temporizadores que se ejecutan más tiempo que RunnableInstancesDetectionPeriod.

No recomendamos reducir el RunnableInstancesDetectionPeriod, ya que esto conduce a una mayor carga en la base de datos de persistencia. Cada host de servicio que usa el SqlWorkflowInstanceStore consulta la base de datos una vez por período de detección. Establecer RunnableInstancesDetectionPeriod en un intervalo demasiado pequeño puede hacer que el rendimiento del sistema disminuya si el número de hosts de servicio es grande.

HostLockRenewalPeriod
Este parámetro define el intervalo con el que el host renueva su bloqueo en la base de datos de persistencia. Acortar este intervalo permitirá una recuperación más rápida de las instancias de flujo de trabajo en caso de que se produzca un error en un host o equipo. Por otro lado, un período de renovación de bloqueo corto aumenta la carga en la base de datos de persistencia. Cada host de servicio que use SqlWorkflowInstanceStore actualizará sus bloqueos en la base de datos una vez por período de renovación. Si un equipo ejecuta muchos hosts de servicio, asegúrese de que la carga producida por la renovación del bloqueo no disminuya el rendimiento del sistema. Si es así, considere aumentar el HostLockRenewalPeriod.

InstanceLockedExceptionAction
Si está habilitado, SqlWorkflowInstanceStore intenta cargar una instancia bloqueada durante los siguientes 30 segundos. Establézcalo InstanceLockedExceptionAction en BasicRetry o AggressiveRetry si el flujo de trabajo recibe varios mensajes en poco tiempo y los equipos diferentes reciben estos mensajes.

Dado que el mecanismo de reintento de carga no introduce ninguna sobrecarga de rendimiento siempre que no se prueben los reintentos de carga, InstanceLockedExceptionAction siempre se debe habilitar.