Optimice el rendimiento para operaciones masivas

Artículo
07/01/2024

Cuando necesita crear o actualizar miles o millones de registros en Dataverse, las elecciones que haga pueden ahorrarle horas de tiempo para completar el proyecto de operación masiva. Este artículo describe los factores que afectan el rendimiento y las opciones que tiene para crear aplicaciones cliente que optimicen el rendimiento para operaciones masivas. También se deben considerar otros factores, como la cantidad de registros, el tamaño de los registros, la latencia de la red y la complejidad de los datos.

Tipo de tabla

El tipo de tabla que elija para almacenar sus datos tiene el mayor impacto en el rendimiento que puede esperar con las operaciones masivas. Dataverse ofrece dos tipos de mesas: estándar y elástica.

Una tabla estándar almacena datos mediante Azure SQL. Las tablas estándar brindan soporte para transacciones y mayores capacidades para modelar Relaciones.
Una tabla elástica almacena datos mediante Azure Cosmos DB. Las tablas elásticas se escalan automáticamente de forma horizontal para manejar grandes cantidades de datos y altos niveles de rendimiento con baja latencia. Las tablas elásticas son adecuadas para aplicaciones con cargas de trabajo impredecibles, puntiagudas o de rápido crecimiento.

Si los tiempos de carga de datos son su principal preocupación, las tablas elásticas proporcionan el mejor rendimiento. Aprenda cuándo usar mesas elásticas

Lógica de negocios

Dataverse proporciona la capacidad de agregar lógica empresarial adicional cuando se crean o actualizan registros mediante complementos. Complementos puede registrarse para ejecutarse sincrónicamente antes o dentro de la transacción de una operación de tabla estándar. Las tablas elásticas admiten complementos que se pueden ejecutar antes de que comience una operación porque no hay ninguna transacción. Cualquier error que ocurra en el código del complemento durante un paso sincrónico para una tabla estándar, o antes de la operación en una tabla elástica, cancela la operación. Un desarrollador de complementos puede generar deliberadamente una excepción para cancelar la operación y garantizar que se aplique la lógica de validación de datos.

Cualquier complemento que esté registrado para ejecutarse de forma sincrónica aumenta el tiempo necesario para que se complete la operación. Para preservar el rendimiento:

Limite el número de complementos síncronos registrados para las operaciones. Agregue lógica para ejecutar de forma asíncrona mediante un complemento asíncrono o flujo de Power Automate a menos que sea esencial que la lógica se aplique de forma sincrónica.
Asegúrese de que los complementos que tiene estén limitados en la lógica que intentan realizar. Si bien los complementos deben completarse dentro de un generoso límite de tiempo de 2 minutos, los complementos sincrónicos que exceden los dos segundos para ejecutarse degradan seriamente el rendimiento.
Asegúrese de que los complementos solo se ejecuten cuando sea necesario. Los complementos para operaciones de actualización se pueden filtrar para que se ejecuten solo cuando se actualizan columnas específicas.
Asegúrese de que los complementos estén optimizados para realizar la lógica de la manera más eficiente posible. Para las tablas estándar, es necesario considerar el impacto que las transacciones y los bloqueos de registros pueden tener en el rendimiento. Obtenga más información sobre el diseño de personalización escalable y otras mejores prácticas para escribir complementos
Elija en qué API registrar su complemento. Puede aplicar lógica síncrona para ejecutarse en las API de operaciones masivas más eficientes CreateMultiple y UpdateMultiple. Aprenda a escribir complementos para CreateMultiple y UpdateMultiple.

Omitir lógica de negocios

Para acelerar el proyecto de operaciones masivas, puede deshabilitar los complementos registrados para las operaciones de creación o actualización para mejorar el rendimiento. Si la lógica empresarial no es esencial, o si planea otros pasos para garantizar la coherencia de los datos, puede deshabilitar manualmente los pasos del complemento y volver a habilitarlos cuando se complete el proyecto de operación masiva. Sin embargo, al deshabilitar los complementos se impide que la lógica se aplique desde cualquier cliente. Cualquier usuario u otro proceso que agregue datos a Dataverse durante este período no se aplicará ninguna lógica empresarial.

Como desarrollador de una aplicación cliente que realiza la operación masiva, puede aplicar un parámetro opcional a las solicitudes que envía para evitar la lógica. Solo un sistema Administrador o usuarios a los que se les ha otorgado un privilegio específico pueden usar este encabezado. Obtenga más información sobre cómo omitir la lógica de Dataverse personalizada.

API de operaciones masivas

Dataverse proporciona API de operaciones masivas que permiten el mayor rendimiento posible para las operaciones de creación y actualización. Estas API incluyen CreateMultiple, UpdateMultiple y UpsertMultiple. Para las tablas elásticas solo, puede usar el mensaje DeleteMultiple.

Si bien estas API proporcionan el mayor rendimiento, tienen las siguientes limitaciones para las tablas estándar:

No disponibles actualmente para todas las tablas. Cualquier tabla personalizada debería admitirlas, pero no todas las tablas de Dataverse principales las admiten, como Cuenta o Contacto. Puede ejecutar una consulta proporcionada en la documentación para determinar si una tabla puede usar estas API.
No perdonar los errores de datos. Debe asegurarse de que los datos que está cambiando se eliminen y validen cuidadosamente. Cualquier error que ocurra dentro de una operación en estas API hace que falle toda la operación.
No se admite su uso en complementos. Actualmente, estas API solo deben ser utilizadas por aplicaciones cliente externas.

Las operaciones masivas están disponibles para todas las tablas elásticas y las tablas elásticas pueden devolver información sobre operaciones individuales que fallan. Obtenga más información sobre las operaciones masivas con tablas elásticas.

API por lotes

Si no puede usar API de operaciones masivas, con el SDK para .NET puede usar ExecuteMultiple, y con la API web puede usar OData $batch.

Utilice estas API para agrupar un conjunto de operaciones en una sola solicitud y lograr una mayor eficiencia principalmente debido a un menor número de solicitudes más grandes, lo que reduce la carga útil total enviada y recibida por cable para cada operación. Una aplicación cliente no necesita esperar a que finalice una operación antes de enviar la siguiente solicitud.

Cada operación dentro de la solicitud se aplica secuencialmente en el servidor, por lo que no se mejora la eficiencia por operación. Sin embargo, debido a que las operaciones se realizan individualmente, puede obtener información sobre qué operaciones fallaron o detener el lote cuando ocurre un error. Puede enviar hasta 1000 operaciones por solicitud, pero para obtener mejores resultados le recomendamos que comience con un número menor y experimente para determinar qué tamaño de lote funciona mejor para su caso.

Nota

Tanto las API de operación masiva como las API por lotes obtienen importantes mejoras de rendimiento cuando se utilizan en paralelo. Consulte Solicitudes paralelas.

Arquitectura de cliente

Dataverse está diseñado como origen de datos para admitir múltiples aplicaciones con una gran cantidad de usuarios simultáneos. Para optimizar el rendimiento, diseñe su cliente para utilizar las fortalezas de Dataverse.

Los cuellos de botella en el código del lado del cliente son la causa principal de los problemas de rendimiento. Con frecuencia, los desarrolladores no utilizan plenamente las capacidades del código, lo que puede afectar el rendimiento. Es crucial optimizar la forma en que la aplicación cliente utiliza los núcleos o la computación de la infraestructura, ya que una falla en la optimización puede afectar significativamente el rendimiento. Por ejemplo, cuando se utilizan Azure Functions, se pueden seguir varios pasos para optimizar el rendimiento, como implementar el escalado automático, usar instancias de preparación, ajustar el uso de la CPU, utilizar varios núcleos y permitir la simultaneidad.

Límites de protección de servicio

Para garantizar una disponibilidad y un rendimiento consistentes para todos, Dataverse aplica algunos límites sobre cómo se utilizan las API. Estos límites están diseñados para detectar cuándo las aplicaciones del cliente demandan recursos del servidor de forma extraordinaria. Los proyectos de operación masiva siempre plantean exigencias extraordinarias, por lo que debe estar preparado para gestionar los errores que regresan los límites de protección del servicio. Si no recibe algunos errores de límite de protección del servicio, no ha maximizado la capacidad de su aplicación.

Los errores de límite de protección del servicio son simplemente otro tipo de error transitorio que su cliente debe estar preparado para manejar, como una pérdida temporal de conectividad de red. Una aplicación cliente resistente debe responder al error esperando y reintentando. La única diferencia es que los límites de protección del servicio le indican cuánto tiempo debe esperar antes de volver a intentarlo.

Lea estos artículos para aprender más:

Solicitudes paralelas

Puede ver una mejora significativa en el rendimiento al enviar solicitudes en paralelo, pero debe comprender cómo enviarlas correctamente.

No todos los ambientes son iguales

No todos los Dataverse entornos tienen asignados el mismo número de recursos de servidor web. Dataverse se adapta a las necesidades del entorno añadiendo más recursos de servidor web para soportarlo. Un entorno de producción que admite miles de usuarios activos requiere más servidores web que un entorno de prueba. Cuando su entorno tiene muchos servidores web, el envío de solicitudes en paralelo puede marcar una gran diferencia en el rendimiento total que puede lograr su aplicación cliente.

Grado recomendado de paralelización (DOP)

Dataverse devuelve datos en un encabezado de respuesta que le indica un grado de paralelización (DOP) recomendado para su entorno. El rendimiento empeora si envía más solicitudes paralelas de las que recomienda el encabezado de respuesta. El hardware del cliente que utiliza para ejecutar su aplicación puede necesitar más núcleos de CPU para enviar tantas solicitudes en paralelo. Es posible que necesite utilizar más clientes para obtener el máximo rendimiento. Por ejemplo, puede usar un servicio de aplicación escalado o una función de Azure.

Dependiendo de la arquitectura del lado del cliente, es posible que necesite dividir el grado de paralelismo recomendado. Por ejemplo, cuando tienes dos clientes y tu DOP recomendado es 50; configure cada cliente para usar 25.

Deshabilitar la afinidad de Azure

Cuando sea apropiado, puede ver mejores resultados cuando configura su cliente para usar todos los servidores web disponibles eliminando la cookie de afinidad de Azure que intenta asociar su aplicación a una sola web. servidor. Deshabilitar la afinidad de Azure no es apropiado para aplicaciones interactivas que usan datos almacenados en caché del servidor para optimizar la experiencia del usuario.

Optimizar la conexión

Cuando utilice .NET, debe aplicar cambios de configuración como los siguientes para optimizar su conexión para que sus solicitudes no estén limitadas por la configuración predeterminada.

// Bump up the min threads reserved for this app to ramp connections faster - minWorkerThreads defaults to 4, minIOCP defaults to 4 
ThreadPool.SetMinThreads(100, 100);
// Change max connections from .NET to a remote service default: 2
System.Net.ServicePointManager.DefaultConnectionLimit = 65000;
// Turn off the Expect 100 to continue message - 'true' will cause the caller to wait until it round-trip confirms a connection to the server 
System.Net.ServicePointManager.Expect100Continue = false;
// Can decrease overall transmission overhead but can cause delay in data packet arrival
System.Net.ServicePointManager.UseNagleAlgorithm = false;

Resumen de recomendaciones

Según los factores descritos anteriormente, siga estas recomendaciones para optimizar el rendimiento de proyectos de operaciones masivas:

Elija un tipo de mesa que se ajuste a sus necesidades. Las mesas elásticas tienen mucha mayor capacidad para operaciones a granel.
Minimice, deshabilite u omita la lógica empresarial personalizada en las tablas que está utilizando. Configure su aplicación cliente para omitir la lógica personalizada cuando sea apropiado.
Usar API de operación masiva de Dataverse cuando pueda; de lo contrario, utilice API por lotes.
Diseñe su aplicación cliente para gestionar errores transitorios, incluidos aquellos errores devueltos por los límites de protección del servicio.
Enviar solicitudes en paralelo. Utilice el encabezado de respuesta para guiarle hasta el grado de paralelismo (DOP) recomendado. Deshabilite la cookie de afinidad cuando corresponda.
Valide los datos para asegurarse de que cumplan con el esquema de columnas de la tabla. Esto puede ayudar a prevenir errores y reducir la cantidad de operaciones fallidas.

Consulte también

Tablas elásticas
Use complementos para ampliar los procesos de negocio
Omitir la lógica de Dataverse personalizada
Mensajes de operación en masa
Escribir complementos para CreateMultiple y UpdateMultiple
Enviar solicitudes paralelas