Saltar al contenido

Ajuste de rendimiento de Jitterbit App Builder

Introducción

El ajuste de rendimiento es un proceso de identificación y resolución de cuellos de botella, comenzando con optimizaciones a nivel de aplicación antes de considerar cambios de infraestructura más costosos.

Esta página cubre las principales áreas de optimización: encontrar problemas, diseño de aplicaciones, optimización de consultas e infraestructura.

Encontrar problemas

Para solucionar problemas de rendimiento, primero necesitas encontrarlos. Puedes utilizar estas herramientas para diagnosticar problemas:

  • Herramientas de desarrollador del navegador: La mayoría de los navegadores web tienen herramientas de desarrollador integradas que pueden ayudarte a encontrar problemas del lado del cliente, como solicitudes de red que son lentas o que fallan. Para más información, consulta Uso de herramientas de desarrollador del navegador.

  • Herramientas específicas de la base de datos: Por lo general, tu sistema de base de datos tiene herramientas para ayudarte a analizar y ajustar el rendimiento de las consultas. Por ejemplo, puedes usar EXPLAIN ANALYZE en PostgreSQL o el Asesor de ajuste del motor de base de datos en Microsoft SQL Server para inspeccionar los planes de ejecución de consultas e identificar problemas.

  • Monitoreo de App Builder: App Builder tiene monitoreo integrado y registros de base de datos que pueden proporcionar información sobre lo que está haciendo la aplicación.

Optimización a nivel de aplicación

Esta sección cubre las optimizaciones que puedes realizar dentro de tu aplicación de App Builder y su esquema de base de datos subyacente.

Índices

En una base de datos, un índice mejora el rendimiento de las consultas al ayudar al motor de la base de datos a encontrar datos más rápido.

Debes examinar el código SQL de tu aplicación y verificar que todas las columnas utilizadas en las cláusulas WHERE, ORDER BY o JOIN estén correctamente indexadas. El objetivo es crear suficientes índices para acelerar tus consultas SELECT sin crear tantos que ralentices significativamente las operaciones de UPDATE, INSERT o DELETE.

Aquí están los puntos clave sobre los índices:

  • Equilibrar lecturas y escrituras: Agregar índices acelera las consultas (lecturas), pero ralentiza las declaraciones de modificación de datos (INSERT/UPDATE/DELETE). Encuentra un equilibrio que funcione para tu aplicación.

  • Índice para ordenar y agrupar: Considera indexar columnas utilizadas para ordenar (ORDER BY) y agrupar (GROUP BY). También puedes beneficiarte de indexar columnas utilizadas en funciones de agregación como MIN(), MAX() y COUNT().

  • Índices cubrientes: Un "índice cubriente" incluye todas las columnas requeridas para una consulta específica. Esto puede ser muy eficiente, ya que la base de datos puede responder a la consulta utilizando solo el índice, sin tener que leer los datos de la tabla en sí. Al crear un índice cubriente, coloca las columnas utilizadas en comparaciones de igualdad (=) antes de las columnas utilizadas en comparaciones de desigualdad (como > y <).

  • Encontrar índices faltantes: Puedes utilizar herramientas nativas de la base de datos para encontrar índices faltantes o no utilizados. (Para ejemplos usando SQL Server, consulta Encontrar índices faltantes y no utilizados en SQL Server.

Consultas

Los siguientes consejos pueden ayudar a mejorar el rendimiento de tus consultas:

  • Escribe cláusulas WHERE amigables con los índices: Evita usar funciones en columnas indexadas, ya que esto puede impedir que la base de datos utilice el índice. Por ejemplo:

    Esta consulta es lenta porque la función LOWER() impide que la base de datos utilice un índice en la columna FirstName. La base de datos debe escanear cada fila.

    WHERE LOWER(FirstName) LIKE '%bob%'

    Esta consulta es rápida porque puede usar un índice para encontrar filas coincidentes directamente.

    WHERE FirstName LIKE 'Bob%'

  • Selecciona solo las columnas necesarias: Evita usar SELECT *. Al seleccionar solo las columnas que tu aplicación necesita, reduces la cantidad de datos que deben ser procesados y enviados a través de la red. Esto es especialmente importante para subconsultas.

  • Simplifica la lógica compleja: Revisa y reescribe consultas que se han vuelto excesivamente complejas o anidadas. Siempre que sea posible, reutiliza subconsultas o divide la lógica compleja en partes más pequeñas y manejables.

Objetos de negocio

Los objetos de negocio a veces pueden causar problemas de rendimiento. Estos son los puntos a considerar al analizar objetos de negocio por problemas de rendimiento sospechosos:

  • Carga de datos: App Builder carga todas las columnas de un objeto de negocio si el panel utiliza cualquiera de los siguientes:

    • Formato condicional.

    • Un campo con Soporte para Sustitución habilitado.

    • Cualquier regla de visibilidad no estática.

    Ten en cuenta este comportamiento al diseñar paneles complejos.

  • Uso de campos:

    • Evita incluir campos binarios en un objeto de negocio a menos que el campo esté siendo utilizado por un panel (como para una carga o descarga de archivos).

    • Considera crear objetos de negocio dedicados que contengan campos binarios solo para paneles que los necesiten específicamente.

    • Asegúrate de usar el tipo de dato correcto para las columnas. Por ejemplo, usa INT para números y TIMESTAMP para fechas, en lugar de VARCHAR o TEXT. Esto reduce el tamaño de almacenamiento y mejora la velocidad de las consultas.

  • Impacto en la interfaz de usuario: Incluso si la consulta de un objeto de negocio es rápida, el usuario puede experimentar un comportamiento lento de la aplicación. Debes verificar otras cosas que podrían afectar la velocidad, como reglas de ordenamiento complejas o cuadros de lista con un gran número de elementos.

Optimización a nivel de infraestructura

Si has optimizado tus aplicaciones tanto como puedes y aún necesitas un mejor rendimiento, puedes considerar actualizar tu infraestructura. Aquí están las opciones:

  • Escalado horizontal con balanceo de carga: A medida que crece el número de usuarios, un solo servidor web puede no ser capaz de manejar la carga. El escalado horizontal implica agregar más servidores web para procesar solicitudes y usar un balanceador de carga para distribuir las solicitudes de manera uniforme entre ellos. Esto no solo mejora el rendimiento, sino que también aumenta la confiabilidad, ya que el tráfico puede ser redirigido si un servidor falla.

    Nota

    Se recomienda el autoescalado y el balanceo de carga para todos los entornos alojados en la nube.

  • Escalado de base de datos: El servidor de base de datos puede ser un cuello de botella de rendimiento en aplicaciones de alto tráfico. Para manejar cargas de trabajo con muchas lecturas, puedes crear réplicas de lectura. Estas son instancias secundarias de base de datos que contienen una copia de los datos de la base de datos primaria. Puedes configurar tu aplicación para enviar todas las consultas de solo lectura a estas réplicas, dejando la base de datos primaria libre para manejar operaciones de escritura.

Para conjuntos de datos extremadamente grandes, se puede considerar el sharding, donde una base de datos se partitiona en piezas más pequeñas (shards) que se distribuyen a través de múltiples servidores.

  • Capas de caché: Para entornos de producción, se debe utilizar un sistema de caché en memoria dedicado, por ejemplo, Redis o Memcached. Estos sistemas almacenan datos de acceso frecuente en RAM, proporcionando tiempos de recuperación mucho más rápidos que una base de datos. Cuando tu aplicación necesita datos, primero verifica la caché y solo consulta la base de datos si no se encuentra la información. Esto puede reducir significativamente la carga en el servidor de la base de datos.

  • Asignación y monitoreo de recursos: Para asegurar que tus servidores estén correctamente dimensionados, se debe monitorear activamente su rendimiento. Realiza un seguimiento de métricas clave como el uso de CPU, el consumo de memoria y el I/O de disco para identificar cuellos de botella antes de que impacten a los usuarios.

    Se deben provisionar los servidores con suficiente CPU, RAM y almacenamiento rápido (SSDs) para manejar la carga de trabajo esperada. El escalado vertical (actualizar a hardware más potente) puede ser una solución temporal antes de que el escalado horizontal se vuelva necesario.

Solución de problemas

Para la solución de problemas relacionada, consulta lo siguiente en la guía de solución de problemas de App Builder: