Msdn optimizando la performance en la web

Preview:

Citation preview

Optimizando la Performance en la Web

Alejandro MihanovichSenior Consultant

Andrés IturraldePremier Field Engineerhttp://blogs.msdn.com/aiturralde

Agenda

• ¿Por qué es importante el rendimiento?

• Desafíos comunes de rendimiento• Analizando problemas de rendimiento• Tácticas para Mejorar el Rendimiento

¿Por qué es importante el rendimiento?− El rendimiento es primordial!− Es crítico en la calidad de cualquier

aplicación− El rendimiento debe ser considerado

desde las etapas iniciales del desarrollo

− Si tus aplicaciones son lentas, tus usuarios se quejaran

Porcentaje de Abandono

* Fuente: How Loading Time Affects Your Bottom Line - http://blog.kissmetrics.com/loading-time/

Desafíos Comunes de Rendimiento− Problemas frecuentes:

− Latencia de la red− Payload Size− Network Round Trips− Conexiones TCP limitadas− Código pobremente optimizado

− No son problemas exclusivos de ASP .NET

Latencia de la Red

Región Average Round-Trip Time (ms) Average Packet Loss (%)

Africa 469 3.70

Australia 204 0.23

Balkans 202 0.74

Central Asia 597 1.24

East Asia 192 0.68

Europa 178 0.48

Latin America 270 1.15

Middle East 279 0.87

North America 59 0.09

Russia 243 2.48

South Asia 424 1.89

South East Asia 254 0.03

* Fuente: Universidad Stanford en Carolina del Norte

Estadísticas de la Red a través Internet por Región

Payload Size & Network Round Trips− Payload Size, tamaño de los datos

transmitidos necesarios para renderizar una página

− Network Round Trips, número de requests TCP necesarios para obtener los datos

− Ejemplos típicos de problemas derivados:− Compresión de contenido no habilitada− Usar múltiples imágenes pequeñas estáticas

Conexiones TCP limitadas

− Especificación HTTP/1.1 sugiere que los browsers deben descargar solo dos recursos a la vez

Tiempo

Arc

hiv

os

HTML

Recurso de la página

Código Pobremente Optimizado− Algunos problemas frecuentes:

− Abuso de redirects− Búsquedas de DNS excesivos− JavaScript y CSS pobremente optimizado− Mal patrón de asignación− Leaks de memoria

Analizando Problemas de Rendimiento− Herramientas recomendadas del lado del

cliente− Fiddler

http://www.fiddler2.com − Network Monitor

http://bit.ly/JF3osx − Visual Round Trip Analyzer (VRTA)

http://bit.ly/JvrrGz

Tácticas para Mejorar el Rendimiento− Reducir el tamaño del payload− Hacer uso eficiente del Cache− Optimizar el tráfico de la red− Organizar y escribir código para mejor

rendimiento

DEMO1. Reducir el tamaño del payload2. Cache eficiente3. Optimizar el tráfico de la red4. Organizar y escribir código para mejor rendimiento

Analizando Problemas de Rendimiento− Herramientas recomendadas del lado del

servidor− Debug Diag 1.2

http://bit.ly/L9MGir − Failed Request Tracing (IIS 7 o superior)

http://bit.ly/vZldlT − LogParser 2.2

http://bit.ly/JeocF5 − Performance Counters (Perfmon)

http://bit.ly/H8ntr0

DEMOAnalizando problemas de rendimiento en el servidor

Tácticas para Mejorar el Rendimiento− IIS 7:

− Application Pool: Integrated Mode− Application Pool: Evitar Reciclaje

− ASP .NET− Liberación correcta de recursos en

memoria− Evitar el mal patrón de asignación− ASP .NET 4.0: Auto-Start− Si no es necesario, evitar: Sesión y/o

ViewState− .NET 4.0: Operaciones Asíncronas

Optimización de la capa de datos // SQL Server− Sistema de administración de datos

relacional (RDBMS)− Desafíos de rendimiento para la Base

de Datos− Costos de Parseo y compilación− Costos del Acceso a los datos− Costo de la “conexión”− Costo de la “transacción”− Implicaciones del “Paginado” de datos en

páginas Web

Optimización de la capa de datos // SQL Server

Parseo y Compilación

Parseo y Compilación

− El motor de datos debe convertir todo batch/sentencia TSQL en programa ejecutable antes de comenzar a retornar resultados

− También debe existir un mecanismo para aprovechar/reutilizar cada segmento de código compilado

− La unidad de abstracción que identifica a un determinado código compilado en SQL Server se llama "Plan de ejecución"

Texto TSQL->Plan

SELECT P.FirstName, P.LastName, SC.AccountNumber, SC.ModifiedDateFROM Sales.Customer AS SCJOIN Person.Person PON SC.PersonID = P.BusinessEntityIDWHERE P.LastName in ('Adams')ORDER BY P.LastName, P.FirstName ;

Parseo y Compilación

− El motor SQL Server conecta una sentencia/batch TSQL con su plan de ejecución mediante un "hash" del texto utilizado para generar dicho plan.Query 1 Se compila y se almacena en el cacheSelect * from Person.Address where AddressID in (1, 2) Query 2 Se compila y se almacena en el cacheSelect * from Person.Address where AddressID in (2, 1) Query 3 Se reutilizaSelect * from Person.Address where AddressID in (1, 2)

Parseo y Compilación

− Aplicaciones Online (OLTP) envían muchas peticiones donde sólo varían los valores en los filtros (WHERE…AND…ETC.) 

− Procesos (DSS), ocurre generalmente lo opuesto.

− El SQL Server solo desecha planes de la memoria bajo condiciones de presión de memoria o si se alcanzó el límite asignado para el procedure cache (~50%-75% de la "memoria disponible“, según el motor SQL)

Parseo y Compilación

− Vistas dinámicas (DMV) en SQL para monitoreo del cache de procedimientosSELECT qs.sql_handle, qs.statement_start_offset, qs.statement_end_offset, qs.creation_time, qs.last_execution_time, 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 ) AS query_text

FROM sys.dm_exec_query_stats qsCROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt

Parseo y Compilación− Consumo de memoria a nivel general

en SQL Server

Parseo y compilación− System Monitor

− Memory Manager:Stolen Server Memory: Todo lo que no es cache de datos

− Memory Manager:Target Server Memory: (Representa la "memoria ideal" consumible por la instancia)

− General Statistics: Logins/Sec− General Statistics:Logouts/Sec− General Statistics:User Connections− SQL Statistics:Batch Requests/Sec− SQL Statistics:SQL Compilations/Sec

Monitoreo General Demos− Comando para limpiar el cache

dbcc freesystemcache('all')

DEMOCosto de parseo y compilación

Optimización de la capa de datos // SQL Server

Acceso a Datos

Acceso a disco

− Tasa de transferencia ordenes de magnitud más lenta que la memoria

− Capacidad del subsistema varía considerablemente si los accesos son aleatorios Vs. secuenciales− IO aleatorio: IOPS (“paquetes” de IO por

segundo)− IO secuencial: Mbytes por segundo

Acceso a disco – Contadores en Windows

− System Monitor− PhysicalDisk o LogicalDisk

− Disk Bytes/Sec− Disk Transfers/Sec− Avg Disk Sec/Transfer− Avg Bytes/Transfer− %Idle time

DEMOAcceso a disco con SQLIO

Operadores Join

Nested Loop

Operador Merge

Operador Hash

Indices

- Estructura de un índice− "Arbol" y "Hoja"− Arbol: “Acceso Directo””− Hoja:

− Está ordenada físicamente (ó podría estarlo)− Se puede recorrer en forma independiende (i.e sin

entrar por el arbol)− Muy importante!!: Conocer qué se almacena

en la hoja− El acceso por el arbol se llama "Index Seek".

El recorrido de la hoja se llama "Index Scan"

Indices

Indices− Indice Nonclustered Vs. Cluster

− El índice nonclustered es el índice que conocemos/imaginamos. Es decir, una estructura separada que “apunta” a la tabla.

− En la "hoja" del nonclustered estan únicamente las columnas del índice (+ columnas incluidas).

− Las columnas "incluidas" forman parte de la hoja, pero no del arbol.

− La "hoja" del índice cluster es la tabla entera ordenada físicamente por las columnas definidas en el índice.

Indices

Indices− Indice Nonclustered Vs. Cluster

− No tiene sentido "incluir" columnas en un índice cluster

− Sólo puede haber un único índice cluster definido para una tabla. Obvio, solo puedo ordenar la tabla entera una sola vez sin "duplicar".

DEMOOperadores Join, Indices

Costo de la conexión− Tráfico extra Handshake TCP/IP

(overhead) y negociados de sesión (autentificación).

− Tráfico de autenticación más pesado en versiones recientes de motor SQL que en anteriores.

− Tiempo de kernel (Switch User<->Kernel)

− Posible agotamiento puertos cliente -> Errores

− Disminución del rendimiento y escalabilidad.

DEMOStress nuevas conexiones, Connection Pooling

Costo de la transacción− Toda modificación a la Base de datos se

realiza dentro del marco de una transacción.− Implícita: INSERT INTO TABLA () VALUES…

(BEGIN TRAN y COMMIT TRAN explícitos)− Explícita: BEGIN TRAN UPDATE..INSERT..ETC

COMMIT TRAN− Durante la transacción, todas las

transacciones se almacenan en un buffer de log en memoria.− Sentencia COMMIT fuerza un “flush” del

buffer del log a disco.− Caso contrario, flush en bloques “grandes”

(256K-1024K)

DEMOCosto de la transacción

DEMO (bonus track)Paginado de datos

¿Preguntas?

© 2009 Microsoft Corporation. All rights reserved. Microsoft, MSDN, the MSDN logo, and [list other trademarks referenced] are trademarks of the Microsoft group of companies.  The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation.  Because Microsoft must respond

to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. 

MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Recommended