Diseño de personalización escalable en Microsoft Dataverse

Nota:

Este es el primero de una serie de artículos sobre el diseño de personalización escalable. Aunque este contenido se ha dividido en artículos independientes, presenta una visión integral de los conceptos, problemas y estrategias que involucran el diseño de personalizaciones escalables. Cada artículo se basa en los conceptos establecidos en los artículos anteriores. Puede descargar estos artículos como un único documento PDF si desea leerlo sin conexión. Seleccione el vínculo Descargar PDF en la tabla de contenido.

Este contenido solo hace referencia a las tablas estándar de Dataverse que usan Azure SQL. Las tablas de tipo elastic de Dataverse utilizan Azure Cosmos DB y no admiten transacciones. Las tablas elásticas tienen características diferentes. Más información sobre las tablas elásticas

Dataverse protege a sí mismo y a sus usuarios de actividades de larga duración que podrían afectar tanto a los tiempos de respuesta del usuario que realizan una solicitud como a la estabilidad y la capacidad de respuesta del sistema para otros usuarios.

Un desafío que enfrentan algunas personas que implementan soluciones de Dataverse son errores producidos por la plataforma o la base de datos subyacente de Microsoft SQL Server cuando estas medidas de protección surten efecto. Estos errores a menudo se interpretan como que la plataforma no puede escalar, terminar o limitar de manera incorrecta las solicitudes al sistema.

Este contenido se basa en experiencias que investigan y abordan las verdaderas causas subyacentes de la mayoría de estos tipos de desafíos. En estos artículos se describe cómo la plataforma se protege contra el impacto de estas solicitudes impuestas en el sistema y explica por qué este comportamiento suele ser el resultado de implementaciones personalizadas que no comprenden el impacto en el bloqueo y el uso de transacciones dentro de la plataforma.

Este contenido también describe cómo optimizar una implementación personalizada para evitar estos tipos de comportamientos no solo evitará errores de plataforma, sino que también permitirá mejorar el rendimiento y las experiencias del usuario final como resultado. Proporciona procedimientos de diseño recomendados e identifica errores comunes que se deben evitar.

La dificultad

La investigación y la resolución de los desafíos de esta área se inician normalmente cuando determinados tipos de errores y síntomas aparecen en el sistema. Estos errores y síntomas a menudo se perciben como problemas en la plataforma y el paso correcto necesario es aflojar las restricciones de la plataforma que normalmente desencadenan una solicitud de ejecución lenta para convertirse en un error notificado.

En realidad, aunque los errores podrían evitarse a corto plazo al relajar algunas de las restricciones de la plataforma, estas restricciones están ahí por buenas razones y están diseñadas para evitar que una acción de ejecución excesivamente larga afecte a otros usuarios o al rendimiento del sistema. Aunque las restricciones podrían relajarse para evitar los errores, los usuarios seguirían experimentando tiempos de respuesta lentos y estos problemas de rendimiento también afectan a la experiencia de otros usuarios del sistema.

Por lo tanto, es preferible examinar las causas principales de por qué se desencadenan estas restricciones y provocan errores y, a continuación, optimizar las personalizaciones de código para evitarlas. Este enfoque proporciona un sistema más coherente y con mayor capacidad de respuesta para los usuarios.

Síntomas comunes

Estos tipos de problemas suelen mostrar una combinación de síntomas comunes, como se muestra en la tabla siguiente.

Síntoma	Description
Solicitudes lentas	Los usuarios ven tiempos de respuesta lentos para el sistema en áreas concretas, por ejemplo, ciertos formularios y consultas.
Errores genéricos de SQL	Algunas acciones responden con un error de plataforma que notifica un error SQL genérico. Este error se traduce a menudo en una capa de la plataforma para un tiempo de espera de SQL.
Interbloqueos	Informes de errores de la plataforma que indican que se produjo una parada, que ha forzado que se terminara la acción y se revierte.
Capacidad de transmisión limitada	Especialmente en escenarios de carga por lotes, esto a menudo muestra que se logra un rendimiento lento, más lento de lo que debería ser posible.
Errores intermitentes/rendimiento lento	Un indicador importante de estos comportamientos es donde la misma acción puede ser rápida o increíblemente lenta, y volver a intentarlo funciona mucho más rápidamente o evita un error.

En realidad una combinación de estos síntomas puede notificarse, y a menudo se hace, a la vez cuando se presentan estas dificultades. No siempre es el caso de que estos síntomas sean un indicador de problemas con el diseño. Otros problemas, como las limitaciones de E/S de disco en la base de datos o un error de producto, pueden causar síntomas similares. Pero la causa más común de estos tipos de síntomas, y por lo tanto uno que merece la pena comprobar, se relaciona directamente con el diseño de la implementación personalizada y cómo afecta al sistema.

¿Por qué deberíamos preocuparnos? ¿Dataverse no se encarga de esto...?

Hace todo lo que puede… Pero usa bloqueos y transacciones para proteger el sistema frente a conflictos cuando sea necesario.

También proporcionamos opciones para tomar decisiones sobre su escenario concreto y decidir dónde es importante controlar el acceso a los datos. Pero esas opciones se pueden tomar incorrectamente y es posible introducir consecuencias no deseadas en el código personalizado. Estos problemas suelen tener un impacto en la experiencia del usuario a través de tiempos de respuesta más lentos, por lo que comprender las implicaciones de ciertas acciones puede dar lugar a resultados más coherentes y mejores para los usuarios.

Comprender las causas

Los síntomas comunes tienen causas que obligan a que determinadas solicitudes se ejecuten lentamente y luego desencadenen restricciones de la plataforma. En el diagrama siguiente se muestran los síntomas típicos con algunas de las causas principales comunes de estos síntomas.

El impacto subyacente de las transacciones de larga duración, el bloqueo de la base de datos y las consultas complejas se pueden superponer entre sí y amplificar sus efectos para causar estos síntomas. Por ejemplo, una serie de consultas de larga duración que son independientes entre sí pueden provocar tiempos de respuesta de usuario lentos, pero solo una vez que requieren acceso a los mismos recursos, los tiempos de respuesta se vuelven tan lentos que se convierten en errores.

Diseño para restricciones de plataforma

La plataforma dataverse tiene muchas restricciones deliberadas que impone para evitar que una acción tenga un impacto demasiado perjudicial en el resto del sistema y, por lo tanto, en los usuarios. Aunque este comportamiento puede ser frustrante, ya que puede impedir que las solicitudes específicas se completen y a menudo conducen a preguntas sobre si se pueden levantar las restricciones, esto rara vez es un buen enfoque cuando se tienen en cuenta las implicaciones más amplias.

Cuando la plataforma se usa según lo previsto y se optimiza una implementación, es raro que haya un escenario en el que se encuentren estas restricciones. Toparse con la restricción es casi siempre un indicador de comportamientos que limitan en exceso los recursos en el sistema. Esto significa que no se pueden procesar otras solicitudes del mismo usuario u otros usuarios. Por lo tanto, aunque puede ser posible aflojar la restricción del bloqueo de la solicitud, esto significa que los recursos que consume están retenidos por aún más tiempo, lo que afecta aún más a otros usuarios.

En el centro de estas restricciones, es la idea de que la plataforma de Dataverse está diseñada para admitir una aplicación transaccional y multiusuario en la que la respuesta rápida a la demanda del usuario es la prioridad. No está pensado para ser una plataforma para el procesamiento por lotes o de larga duración. Es posible impulsar una serie de solicitudes cortas a Dataverse, pero Dataverse no está diseñado para controlar el procesamiento por lotes. Igualmente, cuando hay actividades que ejecutan un procesamiento iterativo grande, Dataverse no está diseñado para controlar ese procesamiento iterativo.

En esos escenarios, se puede usar un servicio independiente para hospedar el proceso de larga duración, redirigiendo directamente las solicitudes transaccionales más cortas a Dataverse. Por ejemplo, usar Flow o hospedar Microsoft SQL Server Integration Services (SSIS) en otro lugar y, a continuación, conducir solicitudes individuales de creación o actualización a Dataverse es un patrón mejor que usar un complemento para recorrer miles de registros que se crean en Dataverse.

Merece la pena conocer y comprender las restricciones de la plataforma que existen, de modo que pueda permitirlas en el diseño de la aplicación. Además, si encuentra estos errores, puede comprender por qué se producen y qué puede cambiar para evitarlos.

Restricción	Description
Tiempos de espera de complementos	• Los complementos se agotarán después de 2 minutos. • No realice operaciones de larga duración en complementos. Esto protege la plataforma, el servicio de espacio aislado y, en última instancia, al usuario de una experiencia de usuario deficiente.
Tiempos de espera de SQL	• Las solicitudes a SQL Server suelen agotar el tiempo de espera en 120 segundos, aunque en algunos casos el tiempo de espera del comando es mayor. • Protege frente a solicitudes de ejecución prolongada • Proporciona protección dentro de una organización determinada y su base de datos privada • También proporciona protección en un nivel de servidor de base de datos frente al uso excesivo de recursos compartidos, como procesadores o memoria.
Límites de flujo de trabajo	• Funciona bajo una política de uso justo • No hay límites estrictos específicos, pero equilibra los recursos entre organizaciones. • Cuando la demanda es baja, una organización puede aprovechar al máximo la capacidad disponible. Donde la demanda es alta, se comparten los recursos y el rendimiento.
Número máximo de conexiones simultáneas	• Hay una configuración predeterminada de la plataforma de un límite máximo de 100 conexiones del grupo de conexiones del servidor web en IIS a la base de datos. Dataverse no cambia este valor. • Si encuentras esto, es una indicación de un error en el sistema; Revisa por qué tantas conexiones están bloqueadas. • Con varios servidores web, cada uno con 100 conexiones simultáneas a la base de datos de 10 ms típica < , esto sugiere un rendimiento de 10 000 solicitudes de > base de datos para cada servidor web. Esto no debería ser necesario y enfrentaría otros desafíos mucho antes.
ExecuteMultiple	• El mensaje ExecuteMultiple está diseñado para asistir en la gestión de colecciones de operaciones que se envían a Dataverse desde un origen externo. • El procesamiento de grandes grupos de estas solicitudes puede vincular recursos vitales en Dataverse a costa de solicitudes más críticas de respuesta por parte de los usuarios.
Límites de protección de servicios	• Para garantizar una disponibilidad y un rendimiento coherentes para todos los usuarios, aplicamos algunos límites a cómo se usan las API. Estos límites están diseñados para detectar cuándo las aplicaciones cliente realizan demandas extraordinarias en los recursos del servidor. • Más información: Límites de la API de protección de servicios

Pasos siguientes

Para comprender cómo se aplican las restricciones de la plataforma, es necesario comprender las transacciones de base de datos. Más información: Diseño de personalización escalable: transacciones de base de datos