3: Problemas de rendimiento

Esta página trata los problemas relacionados con el rendimiento, incluidos los tiempos de espera, la limitación de velocidad y las operaciones lentas.

Limitación de velocidad de la API (HTTP 429)

Error: «HTTP 429: Demasiadas solicitudes» o «Se ha superado el límite de protección del servicio».

Causa: Sus solicitudes superan los límites de velocidad de la API de Dataverse

Síntomas:

• Las operaciones se ralentizan significativamente.

• Fallos esporádicos con intentos de reintento

• Mensajes de error que hacen referencia a «limitación» o «límite de velocidad»

• El progreso se detiene o se invierte al intentar reintentos

Comprensión de los límites de protección del servicio Dataverse:

Microsoft Dataverse aplica límites de protección del servicio para garantizar la estabilidad de la plataforma. Estos límites se evalúan en una ventana móvil de 5 minutos e incluyen:

• Número de solicitudes: 6000 solicitudes por usuario por ventana de 5 minutos

• Tiempo de ejecución: 20 minutos (1200 segundos) de tiempo de ejecución combinado por ventana de 5 minutos.

• Solicitudes simultáneas: 52 solicitudes simultáneas por usuario

Cuando se supera cualquiera de estos límites, Dataverse devuelve un error HTTP 429 y puede incluir un encabezado «Retry-After» que indica cuánto tiempo hay que esperar.

Soluciones:

1. Cambie al ajuste preestablecido de rendimiento «Rate Safe» o «Conservative».

2. Reduzca el número máximo de entidades simultáneas a 2 o menos.

3. Reduzca el tamaño del lote a 100 o menos

4. Ejecute las operaciones durante las horas de menor actividad.

5. Espere 5 minutos antes de volver a intentarlo: la ventana deslizante se restablecerá.

⚠ Importante: si alcanza el límite de velocidad, debe esperar aproximadamente 5 minutos antes de volver a intentarlo. Si lo intenta inmediatamente, seguirá fallando y puede prolongar el período de limitación. La ventana deslizante de 5 minutos significa que, a medida que pasa el tiempo, las solicitudes más antiguas «caducan» en la ventana, liberando capacidad.

💡 Consejo: DvSchemaSync incluye una lógica de reintento integrada que respeta los límites de velocidad. Sin embargo, si experimenta una limitación constante, reduzca la configuración de rendimiento en lugar de depender de los reintentos, ya que estos ralentizan el rendimiento general.

Errores de tiempo de espera

Error: «Tiempo de espera de la operación agotado» o «Tiempo de espera de la solicitud agotado»

Posibles causas:

• Tablas muy grandes que tardan demasiado en sincronizarse

• Problemas de latencia de la red

• Entorno Dataverse con carga elevada

Soluciones:

1. Reducir el tamaño del lote para procesar menos registros por solicitud

2. Sincronizar las tablas individualmente en lugar de todas a la vez

3. Ejecutar durante las horas de menor actividad, cuando el entorno está menos ocupado

Rendimiento lento de la sincronización

Síntomas: Las operaciones de sincronización tardan mucho más de lo esperado.

Consejos de optimización:

1. Habilite el procesamiento paralelo: procese varias entidades simultáneamente.

2. Aumente el tamaño del lote: los lotes más grandes reducen la sobrecarga de la API (si no se alcanzan los límites de frecuencia).

3. Utilice la copia masiva: reduzca el umbral de copia masiva para tablas grandes.

4. Sincronización incremental: tras la sincronización inicial, sincronizar solo los registros modificados.

5. Compruebe los recursos del sistema: asegúrese de que dispone de suficiente CPU, memoria y ancho de banda de red

Problemas de memoria

Error: «Memoria insuficiente» o la aplicación deja de responder.

Causa: Procesamiento de tablas muy grandes o demasiadas operaciones simultáneas.

Soluciones:

1. Reduzca el tamaño del lote para utilizar menos memoria por operación.

2. Reduzca el número máximo de entidades simultáneas para reducir el uso paralelo de memoria

3. Cierre otras aplicaciones para liberar memoria del sistema

4. Cambie al ajuste preestablecido Conservador para obtener el menor uso de memoria.

Tiempos de espera de pausa automática de Azure SQL

Error: tiempo de espera de conexión agotado o «La base de datos está en pausa» en el primer intento de sincronización

Causa: Las bases de datos sin servidor de Azure SQL se pausan automáticamente tras un periodo de inactividad para reducir costes. Cuando DvSchemaSync intenta conectarse a una base de datos en pausa, Azure debe «calentar» la base de datos antes de que pueda aceptar conexiones. Este proceso de calentamiento puede tardar entre 30 y 60 segundos o más, lo que puede superar el tiempo de espera de conexión predeterminado.

Síntomas:

• El primer intento de conexión tras un periodo de inactividad falla por tiempo de espera agotado

• Los intentos de conexión posteriores se realizan correctamente.

• El problema se repite después de que la base de datos haya estado inactiva (normalmente 1 hora sin actividad).

Soluciones:

1. Vuelva a intentar la conexión: simplemente intente la sincronización de nuevo tras una breve espera; la base de datos debería estar lista

2. Precalentar la base de datos: antes de sincronizar, pruebe la conexión en Administración de conexiones para activar la base de datos.

3. Ajuste el retraso de la pausa automática: en Azure Portal, aumente el retraso de la pausa automática o desactívelo para las bases de datos que se utilizan con frecuencia.

4. Programe una actividad regular: configure una tarea programada para consultar la base de datos periódicamente y evitar la pausa.

5. Cambie al nivel aprovisionado: si la pausa automática causa problemas frecuentes, considere cambiar de Serverless a un nivel de computo aprovisionado.

💡 Consejo: Azure SQL Serverless es rentable para un uso intermitente, pero si ejecuta sincronizaciones programadas o necesita tiempos de respuesta constantes, es posible que el nivel Provisioned sea más adecuado.

Recomendaciones sobre los niveles de Azure SQL

La elección del nivel adecuado de Azure SQL depende del volumen de datos, la frecuencia de sincronización y los requisitos de rendimiento. Las siguientes recomendaciones se basan en cargas de trabajo típicas de DvSchemaSync:

Sin servidor frente a computación aprovisionada:

⚠ Importante: Estas son recomendaciones generales. Sus requisitos reales pueden variar en función del número de tablas sincronizadas, el número de registros, la frecuencia de sincronización y los usuarios simultáneos que ejecutan informes en la base de datos. Supervise el uso de DTU/vCore en Azure Portal y amplíe la escala si supera constantemente el 80 % de utilización.