Compartir a través de

Prácticas recomendadas de rendimiento de Fabric API para GraphQL

La API de Microsoft Fabric para GraphQL ofrece una manera eficaz de consultar datos de forma eficaz, pero la optimización del rendimiento es fundamental para garantizar un rendimiento suave y escalable. Tanto si controla consultas complejas como si optimiza los tiempos de respuesta, los procedimientos recomendados siguientes le ayudarán a sacar el mejor rendimiento de la implementación de GraphQL y maximizar la eficacia de la API en Fabric.

Quién necesita optimización del rendimiento

La optimización del rendimiento es fundamental para:

  • Desarrolladores de aplicaciones que crean aplicaciones de alto tráfico que consultan lagos de datos y almacenes de datos de Fabric
  • Ingenieros de datos que optimizan los patrones de acceso a datos de Fabric para aplicaciones de análisis a gran escala y procesos ETL
  • Administradores del área de trabajo de Fabric que administran el consumo de capacidad y garantizan un uso eficaz de los recursos
  • Desarrolladores de BI que mejoran los tiempos de respuesta para aplicaciones de análisis personalizadas basadas en datos de Fabric
  • Los equipos de DevOps solucionan problemas de latencia en aplicaciones de producción que consumen API de Fabric

Use estos procedimientos recomendados cuando graphQL API necesite controlar las cargas de trabajo de producción de forma eficaz o cuando experimente problemas de rendimiento.

Alineación de regiones

Las llamadas API entre regiones son una causa común de alta latencia. Para obtener un rendimiento óptimo, asegúrese de que las aplicaciones cliente, el inquilino de Fabric, la capacidad y los orígenes de datos están todos en la misma región de Azure.

Comprobación de la región del inquilino

Para buscar la región del inquilino de Fabric:

  1. Inicio de sesión en el portal de Microsoft Fabric con una cuenta de administrador
  2. Seleccione el icono de Ayuda (?) en la esquina superior derecha.
  3. En la parte inferior del panel Ayuda, seleccione Acerca de Fabric.
  4. Anote la región que se muestra en los detalles del inquilino.

Comprueba tu región de capacidad

La API de GraphQL se ejecuta dentro de una capacidad específica. Para buscar la región de capacidad:

  1. Abra el área de trabajo que hospeda la API para GraphQL.

  2. Vaya a Configuración del área de trabajo>Información de licencia

  3. Encuentra la región bajo Capacidad de licencia

    Captura de pantalla que muestra cómo obtener la región de capacidad del área de trabajo.

Comprobación de la región del origen de datos

La ubicación de los orígenes de datos también afecta al rendimiento:

  • Orígenes de datos de Fabric (Lakehouse, Data Warehouse, SQL Database): usan la misma región que la capacidad del área de trabajo.
  • Orígenes de datos externos (Azure SQL Database, etc.): compruebe la ubicación del recurso en Azure Portal.

Procedimiento recomendado: implemente aplicaciones cliente en la misma región que la capacidad de Fabric y los orígenes de datos para minimizar la latencia de red.

Procedimientos recomendados de pruebas de rendimiento

Al evaluar el rendimiento de la API, siga estas instrucciones para obtener resultados confiables y coherentes.

Uso de herramientas de prueba realistas

Pruebe con herramientas que coincidan estrechamente con el entorno de producción:

  • Scripts o aplicaciones: utilice scripts de Python, Node.js o .NET que simulan el comportamiento real del cliente.
  • Agrupación de conexiones HTTP: reutilización de conexiones HTTP para reducir la latencia, especialmente importante para escenarios entre regiones
  • Administración de sesiones: mantener sesiones entre solicitudes para reflejar con precisión el uso real

Recursos de ejemplo:

Recopilación de métricas significativas

Para obtener una evaluación precisa del rendimiento:

  1. Automatización de pruebas: use scripts o herramientas de pruebas de rendimiento para ejecutar pruebas de forma coherente durante un período definido.
  2. Preparación de la API: ejecute varias consultas de prueba antes de medir el rendimiento (consulte Requisitos de preparación).
  3. Analizar distribuciones: use métricas basadas en percentiles (P50, P95, P99) en lugar de simplemente promedios para comprender los patrones de latencia.
  4. Prueba bajo carga: mida el rendimiento con volúmenes de solicitudes simultáneos realistas
  5. Condiciones del documento: registre la hora del día, el uso de la capacidad y las cargas de trabajo simultáneas durante las pruebas.

Problemas comunes de rendimiento

Comprender estos problemas comunes le ayuda a diagnosticar y resolver problemas de rendimiento de forma eficaz.

Requisitos de preparación

Problema: la primera solicitud de API tarda significativamente más que las solicitudes posteriores.

Por qué sucede esto:

  • Inicialización de API: cuando está inactiva, el entorno de API debe inicializarse durante la primera llamada, agregando unos segundos de latencia.
  • Calentamiento del origen de datos: muchos orígenes de datos (especialmente los extremos de SQL Analytics y los almacenes de datos) se someten a una fase de calentamiento cuando se accede después de estar inactivos.
  • Inicialización combinada: si la API y el origen de datos están inactivos, los tiempos de inicialización se combinan.

Solution:

  • Ejecutar consultas de prueba de 2 a 3 antes de medir el rendimiento
  • En el caso de las aplicaciones de producción, implemente endpoints de verificación de salud que mantienen la API activa.
  • Considere la posibilidad de usar consultas programadas o herramientas de supervisión para mantener un estado activo durante el horario comercial.

Desalineación regional

Problema: latencia alta de forma coherente en todas las solicitudes.

Por qué ocurre esto: Las llamadas de red entre regiones agregan una latencia significativa, especialmente cuando el cliente, la API y los orígenes de datos se encuentran en diferentes regiones de Azure.

Solution:

  • Compruebe que la aplicación cliente, la capacidad de Fabric y los orígenes de datos están en la misma región
  • Si el acceso entre regiones es inevitable, implemente estrategias de almacenamiento en caché agresivas.
  • Considere la posibilidad de implementar réplicas de API regionales para aplicaciones globales

Rendimiento del origen de datos

Problema: las solicitudes de API son lentas incluso cuando la API está activada y las regiones están alineadas.

Por qué ocurre esto: La API de GraphQL actúa como una interfaz de consulta a través de los orígenes de datos. Si el origen de datos subyacente tiene problemas de rendimiento (como índices que faltan, consultas complejas o restricciones de recursos), la API hereda esas limitaciones.

Solution:

  1. Probar directamente: consulte el origen de datos directamente (mediante SQL u otras herramientas nativas) para establecer un rendimiento de línea base.
  2. Optimice el origen de datos:
    • Adición de índices adecuados para columnas consultadas con frecuencia
    • Considere el almacén de datos adecuado para su caso de uso: Guía de decisión de Fabric: elija un almacén de datos.
    • Revisión de los planes de ejecución de consultas para las oportunidades de optimización
  3. Capacidad dimensionada correctamente: asegúrate de que la SKU de capacidad de Fabric proporciona recursos de computación suficientes. Consulte Conceptos de Microsoft Fabric para obtener instrucciones sobre cómo seleccionar la capacidad adecuada.

Diseño de consultas

Problema: algunas consultas funcionan bien, mientras que otras son lentas.

Por qué sucede esto:

  • Solicitud excesiva de datos: solicitar más campos de los necesarios aumenta el tiempo de procesamiento.
  • Anidamiento profundo: las consultas con muchos niveles de relaciones anidadas requieren varias ejecuciones de resolución
  • Filtros que faltan: las consultas sin filtros adecuados pueden devolver datos excesivos

Solution:

  • Solicite solo los campos que necesita en la consulta de GraphQL.
  • Limitar la profundidad de las relaciones anidadas siempre que sea posible
  • Uso de filtros y paginación adecuados en las consultas
  • Considere la posibilidad de dividir consultas complejas en varias consultas más sencillas cuando sea necesario.

Contenido relacionado

  • Last updated on