Depuración y mejora del rendimiento en Jitterbit App Builder
Herramientas desarrollador de Chrome
Chrome DevTools es un conjunto de herramientas desarrollador web integradas en el navegador Google Chrome. Con DevTools de Chrome, puedes diagnosticar problemas en el App Builder con solicitudes que no se responden o gestionan correctamente, registrar un archivo HAR para su posterior resolución y detectar problemas con los tiempos de carga de las páginas.
Chrome DevTools también proporciona herramientas para capturar capturas de pantalla, emular la experiencia de un usuario móvil y analizar las solicitudes que realiza la página a medida que se carga para identificar áreas específicas que impactan el tiempo de carga de la página.
Nota
Para descargar Google Chrome: https://www.google.com/chrome/
Identificar códigos de error HTTP con Chrome
Chrome DevTools te permite ver y filtrar rápidamente los códigos de error HTTP para ayudarte a aislar e identificar un error en una solicitud de App Builder que no se responde o gestiona correctamente. Los códigos de estado de respuesta HTTP indican si una solicitud HTTP específica se ha completado correctamente.
Desde la pestaña Red de Chrome DevTools, puedes filtrar rápidamente la información resultante haciendo clic en los encabezados de columna. Aquí puedes hacer clic en Estado para ver los resultados del código HTTP e identificar las tareas que no devuelven un resultado 200 OK.
En la captura de pantalla de ejemplo, desde la pestaña Red de Chrome DevTools, vemos que la página de la aplicación muestra los mensajes de error 500 Error interno del servidor y 504 Tiempo de espera de la puerta de enlace. La información contenida en la columna Nombre de este resultado ayuda a definir en qué parte del App Builder se origina este error.
A continuación se muestra una lista de los resultados de códigos de error HTTP más comunes:
- 301 Se trasladó permanentemente
- 302 encontrados
- 307 Redirección temporal
- 308 Redirección permanente
- 400 Solicitud incorrecta = Error del cliente
- 401 No autorizado = Error del cliente
- 403 Prohibido = Error del cliente
- 404 No encontrado = Error del cliente
- 405 Método no permitido = Error del cliente
- 500 Error interno del servidor = Error del servidor
- 502 Puerta de enlace incorrecta = Error del servidor
- 503 Servicio no disponible = Error del servidor
- 504 Tiempo de espera de puerta de enlace = Error del servidor
Nota
Para obtener más códigos de error HTTP, consulte: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
Generar un archivo har con Chrome
Al solucionar problemas complejos de App Builder, puede ser útil o incluso solicitado por un desarrollador de App Builder tener un archivo HAR registrado y generado desde las herramientas de Chrome Web Developer para una mejor identificar y solucionar problemas. Un archivo HAR captura un registro de las solicitudes y la actividad de la red en el momento en que ocurre el problema. En concreto, un HAR es un formato de archivo JSON para registrar la interacción de un navegador web con un sitio web.
Para generar un archivo har:
- Abra Google Chrome y vaya a la página del App Builder donde ocurre el problema.
- Desde la barra de menú de Chrome, seleccione Ver > Desarrollador > Herramientas para desarrolladores
- Desde el panel abierto en la parte inferior de la pantalla, seleccione la pestaña Red
- Busca el botón rojo y redondo de Grabar en la esquina superior izquierda de la pestaña Red y asegúrate de que esté rojo. Si está gris, haz clic en él una vez para iniciar la grabación.
- Marque la casilla junto a Conservar registro
- Haga clic en el botón Borrar para borrar cualquier registro existente de la pestaña Red
-
Ahora intenta reproducir el problema que estabas experimentando antes, mientras se graban las solicitudes de red.
-
Una vez que reproduzca el problema, haga clic derecho en la cuadrícula de solicitudes de red, seleccione Guardar como HAR con contenido y guarde el archivo en su computadora.
Para obtener más información: consulte "Comience a analizar el rendimiento de la red en Chrome DevTools" https://developers.google.com/web/tools/chrome-devtools/network-performance/
Identificar problemas de rendimiento con Chrome
Las herramientas de Chrome DevTools pueden ayudarte a identificar problemas de rendimiento en tu app de App Builder. Si primero accedes a la página donde experimentas un problema de rendimiento, puedes abrir DevTools, revisar la pestaña Red y ordenar por la columna Tiempo. Ordena para ver qué solicitudes tardan más. Las columnas Nombre e Iniciador correspondientes te ofrecen información adicional sobre la solicitud que se origina en la app de App Builder.
Tenga en cuenta que si en los resultados de la pestaña Red encuentra que las solicitudes llamadas filter? ocupan la mayor parte del tiempo de carga de la página, esto indica que probablemente necesite optimizar el objeto comercial correspondiente.
Los objetos de negocio (u objetos de datos) pueden causar tiempos de carga lentos. Si detecta que una solicitud de larga duración proviene de un objeto de negocio, consulte la siguiente sección, que describe las razones por las que un objeto de datos es lento y las opciones para mejorar la velocidad.
Razones por las que un objeto comercial es lento y opciones para mejorar la velocidad
Dependiendo de su configuración, los objetos de negocio (también conocidos como objetos de datos) pueden causar problemas de rendimiento o lentitud en las aplicaciones de App Builder. Entre las razones específicas por las que un objeto de negocio podría ser lento se incluyen:
- La lógica SQL contiene muchas subconsultas
- Se utilizan columnas innecesarias en la lógica.
- Las cláusulas Where no utilizan declaraciones compatibles con índices
- Los índices no están definidos en una(s) tabla(s) que utiliza un objeto de datos
- Índices redundantes en las tablas a las que hace referencia la lógica SQL
- Unión en columnas calculadas
- El uso del índice puede perderse debido a la lógica que se ejecuta en las funciones.
- El campo binario se incluye cuando un panel no lo utiliza
- Solo incluya campos binarios en objetos comerciales si se utilizan como control de archivo
- Vale la pena crear objetos de negocio específicamente para usar en paneles donde se carga o descarga un archivo
- App Builder cargará todas las columnas de un objeto comercial bajo las siguientes condiciones:
- Existe formato condicional
- Si un campo tiene habilitada la sustitución de soporte
- Si un panel tiene reglas de visibilidad no estáticas
Los objetos de negocio aún pueden causar tiempos de carga lentos en las páginas de la aplicación, incluso si los resultados del objeto de negocio resultante se cargan rápidamente. Verifique si hay elementos en la página de su aplicación que afecten la velocidad, como la ordenación, los cuadros de lista u otras configuraciones de la capa de interfaz de usuario, que puedan causar tiempos de carga más lentos.
Aplanamiento de consultas SQL
Si ha identificado que un objeto comercial específico está causando problemas de rendimiento, puede existir una oportunidad de mejorar la lógica SQL y potencialmente simplificar la consultar.
- La mayoría de las veces debes reutilizar las subconsultas.
- A veces, una consultar puede llegar a ser tan grande con subconsultas anidadas que se ejecuta lentamente; solo entonces debe revisarse y reescribirse.
- Aplanar la consultar (eliminar subconsultas innecesarias) generalmente mejora el rendimiento
- Puede examinar el plan de ejecución y los índices
Eliminar columnas no utilizadas
A menudo, las consultas con problemas de rendimiento utilizan columnas en la lógica SQL que son innecesarias.
- Con frecuencia encontramos que las consultas con problemas de rendimiento tienen subconsultas que seleccionan muchos más datos que los que utiliza la consultar externa.
- Eliminar estas columnas (en particular las columnas que se calculan) mejorará el rendimiento.
- Utilice Copiar regla y comience a realizar cambios Calcula el tiempo que tarda en devolverse "Resultados". También calcula el tiempo que tarda en devolverse "Cargar más filas".
Declaraciones amigables con el índice en cláusulas WHERE
La cláusula Where define la condición de búsqueda de una sentencia SQL y, por lo tanto, se encuentra dentro del dominio funcional principal de un índice: la búsqueda rápida de datos. Una cláusula Where mal escrita suele ser la causa de una consultar SQL lenta. Una cláusula Where debe ser eficiente e incluir los índices correctos.
Malo (no se utilizarán índices):
- Donde LOWER(Nombre) como '%Bob%
- Donde NOW() > DATEADD(minutos,60,HoraInicio)
Bueno (índices utilizados):
- Donde Nombre como 'Bob%'
- Donde DateAdd(minutos,-60,AHORA()) > HoraInicio
SQL Server tiene un modo de seguimiento y utilidades de plan de consultar que puede ejecutar para ver si se están utilizando índices.
Configuraciones para mejorar el rendimiento
Esta sección ilustrará las configuraciones de App Builder que afectan el rendimiento. Evite buscar/filtrar/ordenar en columnas de tablas grandes que no estén indexadas cuando se detecten consultas lentas y los índices no sean una opción.
En el nivel del Panel, habilitar Descarga de soporte y tener la Búsqueda simple activada y configurada como Solo indexada puede ayudar a mejorar el rendimiento.
Nota
Al buscar campos indexados, App Builder genera consultas compatibles con el índice:
…FirstName like 'Bob%'…
Will match: "Bob Smith"
Will not match: "Mr Bobert"
Índices y qué debe indexarse
En SQL, un índice se utiliza para acelerar el rendimiento de las consultas, ya que permite obtener datos más rápidamente de SQL Server. Esto se logra reduciendo el número de páginas de datos de la base de datos que deben visitarse o escanearse. Al considerar los índices en los objetos de datos de App Builder, se necesitan suficientes índices para acelerar las consultas SELECT y, al mismo tiempo, evitar la creación de índices redundantes que podrían ralentizar las operaciones UPDATE/DELETE.
Las arquitecturas de índices se clasifican en agrupadas y no agrupadas. Los índices agrupados son índices cuyo orden de las filas en las páginas de datos corresponde al orden de las filas del índice. Por ello, solo puede existir un índice agrupado en una tabla, mientras que pueden existir varios índices no agrupados.
En App Builder, los índices se crean en objetos de tabla. En general, cada tabla debe tener un índice agrupado para permitir una búsqueda eficiente de sus datos. Si a una tabla le falta un valor de índice, esto puede ralentizar la aplicación. Asegúrese de que la clave principal de cada tabla y cualquier columna de clave única existente estén indexadas. Al considerar modificar índices en App Builder, tenga en cuenta los siguientes puntos clave:
Se busca equilibrar la creación de índices con el impacto en el rendimiento que tendrán las sentencias de inserción/actualización. Añadir índices acelerará las consultas, pero ralentizará las de inserción/actualización/eliminación. También debe considerar indexar las columnas que usa para ordenar y las que usa en una expresión de agrupación. Podría ser beneficioso indexar las columnas que las funciones MIN(), MAX(), COUNT(), SUM() y AVG() usan para agregar los datos. - Puede aprovechar los "índices de cobertura", donde tiene un índice más grande que puede ser aprovechado por consultas que utilizan subconjuntos de las columnas. - El orden de las columnas en el índice es importante - La recomendación es que las columnas de desigualdad aparezcan después de las columnas de igualdad en los índices de cobertura.
Herramientas de índice faltantes
Existen utilidades y consultas de SQL Server que pueden utilizarse para facilitar la revisión de índices. Las vistas de administración dinámica (DMV) son utilidades de SQL Server que devuelven información sobre el estado del servidor y permiten supervisar el estado del servidor de bases de datos y diagnosticar problemas. Las DMV ofrecen información detallada sobre lo que ocurre en SQL Server. Para ejecutarlas, se requiere el permiso "VIEW DATABASE STATE" en la base de datos en cuestión.
Puede identificar índices faltantes en sus consultas SQL principalmente de tres maneras:
- Ejecución del Asesor de ajuste del motor de base de datos
- Ejecución de vistas de administración dinámica de índices faltantes
- SQL Server Engine indica índices faltantes al generar planes de ejecución en SSMS
A continuación se presentan tres consultas SQL que se utilizan a menudo para ayudar a identificar problemas con los índices:
FindingLongRunningQueries.sql
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT TOP 20
CAST(qs.total_elapsed_time / 1000000.0 AS DECIMAL(28, 2))
AS [Total Duration (s)]
, CAST(qs.total_worker_time * 100.0 / qs.total_elapsed_time
AS DECIMAL(28, 2)) AS [% CPU]
, CAST((qs.total_elapsed_time - qs.total_worker_time)* 100.0 /
qs.total_elapsed_time AS DECIMAL(28, 2)) AS [% Waiting]
, qs.execution_count
, CAST(qs.total_elapsed_time / 1000000.0 / qs.execution_count
AS DECIMAL(28, 2)) AS [Average Duration (s)]
, SUBSTRING (qt.text,(qs.statement_start_offset/2) + 1,
((CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2) + 1) AS [Individual Query]
, qt.text AS [Parent Query]
, DB_NAME(qt.dbid) AS DatabaseName
, qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qs.total_elapsed_time > 0
ORDER BY qs.total_elapsed_time DESC
IdentifyMostImportantMissingIndexes.sql
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT TOP 20
ROUND(s.avg_total_user_cost *s.avg_user_impact* (s.user_seeks + s.user_scans),0) AS [Total Cost]
, d.[statement] AS [Table Name]
, equality_columns
, inequality_columns
, included_columns
FROM sys.dm_db_missing_index_groups g
INNER JOIN sys.dm_db_missing_index_group_stats s
ON s.group_handle = g.index_group_handle
INNER JOIN sys.dm_db_missing_index_details d
ON d.index_handle = g.index_handle
WHERE d.database_ID = DB_ID()
ORDER BY`[Costo total] `DESC
IdentityUnusedIndexes.sql
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT
DB_NAME() AS DatabaseName
, SCHEMA_NAME(o.Schema_ID) AS SchemaName
, OBJECT_NAME(s.[object_id]) AS TableName
, i.name AS IndexName
, s.user_updates
, s.system_seeks + s.system_scans + s.system_lookups AS [System usage]
INTO #TempUnusedIndexes
FROM sys.dm_db_index_usage_stats s
INNER JOIN sys.indexes i
ON s.[object_id] = i.[object_id]
AND s.index_id = i.index_id
INNER JOIN sys.objects o
ON i.object_id = O.object_id
WHERE 1=2
EXEC sp_MSForEachDB 'USE [?];
INSERT INTO #TempUnusedIndexes
SELECT TOP 20
DB_NAME() AS DatabaseName
, SCHEMA_NAME(o.Schema_ID) AS SchemaName
, OBJECT_NAME(s.[object_id]) AS TableName
, i.name AS IndexName
, s.user_updates
, s.system_seeks + s.system_scans + s.system_lookups
AS [System usage]
FROM sys.dm_db_index_usage_stats s
INNER JOIN sys.indexes i
ON s.[object_id] = i.[object_id]
AND s.index_id = i.index_id
INNER JOIN sys.objects o ON i.object_id = O.object_id
WHERE s.database_id = DB_ID()
AND OBJECTPROPERTY(s.[object_id], ''IsMsShipped'') = 0
AND s.user_seeks = 0
AND s.user_scans = 0
AND s.user_lookups = 0
AND i.name IS NOT NULL
ORDER BY s.user_updates DESC'
SELECT TOP 20 *
FROM #TempUnusedIndexes
ORDER BY`[actualizaciones de usuario] `DESC
DROP TABLE #TempUnusedIndexes
Uso de sentencias SQL desde registros y optimizador de índices
Una vez identificado un objeto de negocio con problemas de rendimiento, puede recuperar la lógica de la sentencia SQL de los registros de App Builder y ejecutarla mediante una utilidad de optimización de índices para identificar áreas de mejora. Esto podría permitir, por ejemplo, identificar índices que se deben agregar.
Para recuperar la lógica de la sentencia SQL, navegue en la aplicación hasta la página donde se utiliza el objeto de negocio. Desde aquí:
- Vaya a IDE > Monitoreo
- Haga clic en Registros de base de datos en el menú
- Haga clic en el botón Editar configuración
- Haga clic en Editar
-
En la sección Configuración del registro de memoria, configure la Gravedad mínima en Seguimiento.
Importante
Siempre restablezca el valor de Gravedad mínima a Desactivado cuando termine de capturar información del registro.
-
Haga clic en el botón Guardar
- Ahora debería ver la pantalla Registros rápidos en App Builder, que consta de 500 líneas de datos de registro (a menos que modifique ese valor). Desplácese por los datos de registro hasta encontrar la lógica de la instrucción SQL que busca.
-
Copie toda la lógica de la sentencia SQL, comenzando por SELECT. Por ejemplo:
-
Haga clic en el botón Editar configuración
- Haga clic en Editar en la pantalla Configuración de registro
- En la sección Configuración del registro de memoria, configure Gravedad mínima en Desactivado
- Inicie SQL Server Management Studio
- Conéctese a su conexión de base de datos
- Hay algunas rutas diferentes que puede aprovechar en SQL Server Management Studio para, en última instancia, optimizar mejor parte de la lógica de las declaraciones SQL que utiliza su aplicación.
- Puede hacer clic en el botón Nueva consulta y configurar la Base de datos disponible en la base de datos correspondiente a la aplicación que está revisando.
-
Ingrese la siguiente sintaxis de consultar, que es una consultar para encontrar las 10 consultas SQL principales que utilizan la mayor cantidad de recursos (lecturas, escrituras, tiempo de trabajo (CPU), etc.):
-
Haga clic en el botón Ejecutar
-
Los resultados mostrarán las 10 consultas SQL que más tardan en devolver información en tu aplicación. Ten en cuenta que la segunda entrada de nuestra captura de pantalla de ejemplo devuelve la misma consultar que identificamos anteriormente (SELECT TOP 2…).
-
Haga clic en el botón Nueva consulta de la barra de herramientas.
- Ingrese la lógica de la declaración SQL que copió de los registros de App Builder
-
Seleccione la base de datos correspondiente en el menú de selección de bases de datos disponibles
-
Si utiliza una base de datos de SQL Server (SQL Express no es compatible), puede hacer clic con el botón derecho del ratón dentro del panel Consulta SQL y seleccionar "Analizar consulta" en el Asesor de optimización del motor de base de datos. Aquí también puede aprovechar la utilidad del plan de ejecución, que trazará el recorrido de la sentencia SQL por la base de datos de la aplicación y ayudará a identificar áreas que podrían estar requiriendo mucho tiempo de optimización.
El ajuste de bases de datos es un conjunto de habilidades técnicas y complejas que requieren los permisos adecuados para acceder y ver las bases de datos y debe realizarse de manera metódica, cuidadosa y con pruebas rigurosas durante todo el proceso para garantizar que el resultado neto sea positivo.
Recursos
- Ajuste del rendimiento de consultas (SQL Server Compact): https://technet.microsoft.com/en-us/library/ms172984(v=sql.110).aspx.aspx)
- SQL Server 2017 - "Vistas y funciones de administración dinámica relacionadas con el índice (Transact-SQL)" de Microsoft: https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/index-related-dynamic-management-views-and-functions-transact-sql?view=sql-server-2017