Diseño de personalización escalable: problemas de simultaneidad

Nota:

Este es el tercero de una serie de temas sobre el diseño de personalización escalable. Para empezar al principio, consulte Diseño de personalización escalable en Microsoft Dataverse. El tema anterior Diseño de personalización escalable: las transacciones de base de datos describen cómo se aplican las transacciones de base de datos y el efecto que tienen en diferentes tipos de personalizaciones.

Cuando tiene solicitudes simultáneas, la posibilidad de colisiones en los bloqueos se incrementa. Cuanto más tiempo tarden las transacciones, más tiempo se mantienen los bloqueos. Las posibilidades son incluso mayores de colisión y el impacto general sería mayor en los usuarios finales.

También debe conocer las diversas formas en que se puede realizar una actividad en la aplicación, y cada una de ellas hace bloqueos que podrían producir conflictos con otras acciones dentro del sistema. En estos casos, el bloqueo impide incoherencias de los datos que se producen cuando se producen acciones superpuestas en los mismos datos.

Algunas áreas clave en las que se debe pensar en el diseño y comprobar si hay problemas son:

• Actividad controlada por el usuario: directamente a través de la interfaz de usuario.
• Acciones asincrónicas: actividad que se produce más adelante como resultado de otras acciones. No se conoce cuándo esta actividad se procesará en el momento de desencadenar la acción de inicio.
• Actividades por lotes: controladas desde Dataverse, como la eliminación masiva de trabajos o el procesamiento de sincronización del lado servidor), o controladas desde orígenes externos, como la integración desde otro sistema.

Operaciones asincrónicas en paralelo

Un error común es que los flujos de trabajo o los complementos asincrónicos se procesan en serie desde una cola y no debería haber conflictos entre ellos. Esto no es preciso, ya que Dataverse procesa varias actividades asincrónicas en paralelo dentro de cada instancia de servicio asincrónica y entre instancias de servicio asincrónicas distribuidas en distintos servidores para aumentar el rendimiento. Cada servicio asincrónico recupera realmente los trabajos que se van a realizar en lotes de aproximadamente 20 por servicio en función de la configuración y la carga.

Si inicia múltiples actividades asincrónicas desde el mismo evento en el mismo registro, seguramente se procesarán en paralelo. Cuando se activan en el mismo registro, un modelo común se actualiza al mismo registro primario; por lo tanto, hay muchas posibilidades de conflicto.

Cuando se produce un evento de desencadenamiento, como la creación de una cuenta, la lógica asincrónica en Dataverse puede crear entradas en la entidad AsyncOperation (trabajo del sistema) para cada proceso o acción que se va a realizar. El servicio asincrónico supervisa esta tabla, recoge las solicitudes en espera en lotes y, a continuación, las procesa. Dado que los flujos de trabajo se desencadenan al mismo tiempo, es muy probable que se recojan en el mismo lote y se procesen al mismo tiempo.

Por qué es importante comprender las transacciones

En el ejemplo de numeración automática se proporciona un escenario que muestra cómo deben tenerse en cuenta las transacciones de base de datos y los problemas de simultaneidad al diseñar personalizaciones escalables.

Serialización y tiempos de espera

Un alto grado de serialización suele ser lo que convierte el bloqueo en tiempos de espera y un rendimiento deficiente. Cuando tiene muchas solicitudes simultáneas, una vez que se serializan y requieren mucho tiempo para procesarse, cada solicitud a su vez tarda cada vez más hasta que se empieza a enfrentar los tiempos de espera y, por consiguiente, a errores.

El tiempo de espera del complemento empieza con cuando se inicia. Un tiempo de espera de SQL se calcula en la solicitud de la base de datos, por lo que si una consulta se bloquea esperando durante mucho tiempo, puede agotarse el tiempo de espera.

Cadena de acciones

Además de comprender las consultas específicas en las actividades desencadenadas directamente, también es necesario tener en cuenta dónde puede producirse una cadena de eventos relacionados.

Cada solicitud de mensaje realizada en un complemento o como paso en un flujo de trabajo sincrónico no solo desencadena la acción directa, sino que también puede provocar que se activen otros complementos y flujos de trabajo sincrónicos. Cada una de estas actividades asincrónicas se producirá en la misma transacción, incrementando la duración de esa transacción y los bloqueos retenidos probablemente mucho más tiempo de lo que puedan realizarse.

El efecto general puede ser mucho mayor que inicialmente realizado. Esto a menudo puede ocurrir involuntariamente donde varias personas están creando la implementación o evoluciona con el tiempo.

Encontrar restricciones de la plataforma

Aquí es donde pueden entrar las restricciones de la plataforma. Y en realidad este tipo de comportamiento existe para proteger a la totalidad del sistema de este tipo de comportamiento.

Siempre que se produzca este nivel de retraso de procesamiento, tendrá consecuencias imprevistas en otras áreas del sistema y en otros usuarios. Por lo tanto, es importante evitar que este tipo de actividad interfiera con el rendimiento del sistema.

Aunque la manera fácil de evitar los errores puede ser relajar las restricciones de la plataforma, esto no aborda el impacto más fundamental en la escalabilidad general y el rendimiento del sistema. Esto debe solucionarse mediante la corrección y la prevención del comportamiento que desencadena las restricciones en primer lugar.

Impacto en el uso

Lo que a menudo también tiene un impacto en el uso es una serie en cascada de implicaciones de este comportamiento.

El problema inicial son los bloqueos y, por tanto, el bloqueo del sistema. Esto conduce a tiempos de respuesta de usuario lentos, que luego se amplifican como tiempos de respuesta de usuario impredecibles y poco confiables, a menudo en un área determinada del sistema.

En el caso extremo o bajo una carga más pesada que la normal, esto puede mostrarse en cualquier procesamiento por lotes en segundo plano con un rendimiento deficiente. Finalmente, todo puede dar lugar a errores que se producen en el sistema.

Es común que, al investigar errores de tiempo de espera en SQL, los usuarios también informen sobre tiempos de respuesta deficientes e imprevisibles, y no se había establecido una conexión entre estos como problemas relacionados.

Pasos siguientes

Comprenda los patrones de diseño que puede aplicar (o evitar) para minimizar los problemas de rendimiento. Más información: Diseño de personalización escalable: Patrones de diseño de transacciones