Java Experto: rendimientoseminarisempresa.fib.upc.edu/aulesempresa/2011/programes/Bitendia… ·...

Java Experto: rendimiento

Marc Clausell Samitier

http://www.aulesempresa.upc.edu/aulesempresa/2011.html http://www.bitendian.com

Temario (1)

• Perfiles de memoria.

• Espacios de memoria y direccionamiento del JVM.

• Algoritmos del Garbage Collection.

• Parámetros en la línea de comandos del JVM.

• Optimización inicial del heap.


Temario (2)

• Optimización en detalle del heap.

• Ciclo de vida de los objetos.

• Monitorización de aplicaciones en producción.

• Combinación de herramientas.


Temario (3)

• Impacto del rendimiento

• Herramientas de optimización

• Metodologías de tuning y proceso de optimización


Motivación

• Problema típico:– Caídas en producción periódicas.

– Degradación del rendimiento.

• Solución típica:– Reiniciar el servidor.


Motivación

• Impacto de un bajo rendimiento:– pérdida de productividad (afecta al cliente)

– pérdida de confianza y credibilidad (os afecta a vosotros)

– pérdida de ingresos (cliente y/o empresa desarrolladora)


Complicaciones

• Evolución de las aplicaciones Java.

• Modelo de ejecución estratificado.

• Frameworks.


Complicaciones (2)

• Modelo de ejecución:– Complejidad

horizontal– Complejidad

vertical


Complicaciones (3)• Ventajas de usar frameworks:

– Aumentan la productividad

– Grandes comunidades opensource evolucionan rápidamente el framework

– Popularidad == testing– Orientación genérica => fácil de ampliar


Complicaciones (4)• Desventajas de usar Frameworks:

– Efecto caja negra

– Solventar un problema interno requiere convertirse en experto

– Hacer un branch tiene implicaciones


Metodología (1)• Primero de todo …

– Conocer la arquitectura de la aplicación y el entorno

– Plantearse: es realmente esta arquitectura necesaria?

– Tener claros los objetivos de mejora• Rendimiento

• Escalabilidad


Metodología (2)• Arquitectura de la aplicación y el entorno:

– Sistema Operativo donde haya servicios relacionados con la aplicación.

– Componentes tecnológicos J2EE en cada estrato.

– Componentes tecnológicos no-java en cada estrato.

– Dependencias externas:• BD, servlets remotos, …

– Topología de red


Metodología (4)

• Rendimiento de la aplicación– Concepto ambiguo– Depende del stakeholder


Metodología (5)• Problemas relacionados con el rendimiento:

– Aplicaciones lentas– Aplicaciones que se degradan con el tiempo– memory-leaks pequeños que degeneran

gradualmente– memory-leaks grandes que tumban el servidor– picos de CPU periódicos– el comportamiento de la aplicación cambia

drásticamente con el aumento de carga– anomalías en producción que no se consiguen

reproducir en desarrollo


Metodología (6)

• APM vs APT– Aplication Performance Management

– Aplication Performance Tuning

• APM incluye APT

• ¿Cuando aplicar APM?


Metodología (7)


• Diseño de la arquitectura:– considerar los ciclos de vida de los objetos

• Ej.: EntityBeans para objetos read-only


Metodología (8)


• Desarrollo:– test unitarios– test unitarios de rendimiento

• memoria (uso del heap)• code-profiling (eficiencia de algoritmos)

• coverage (determinar que porciones de código se ejecutan más frecuentemente)


Metodología (9)


• QA (Quality Assestment):– Validar que se cumplen los SLA una vez

integrado el código


Metodología (10)


• Preproducción– Test de carga

• Producción– Con “fuego real”


Métricas (1)

• Cuantificación del rendimiento– Definición de rendimiento:

• Depende de los SLAs

• Depende de cada stakeholder

– Métricas generales– Métricas específicas


Métricas (2)

• Definición de los SLAs:– Service Level Agreement

– ¿Quién los define?– Propiedades necesarias:

• Específico

• Flexible

• Realista


Métricas (3)

• Métricas generales:– Tiempo de respuesta al usuario final

• #

• Min

• Max• Avg• Stddev

– Throughput de peticiones


Métricas (4)

• Métricas específicas (uso de recursos):– Heap

– Thread pools– JDBC connection pools– Caches– Pools– JMS servers– JCA connection pools


Análisis de rendimiento (1)

• Adquisición de datos– ¿Qué?– ¿Dónde?– ¿Cómo?



• Adquisición de datos: ¿Qué?– Determinar granularidad

• Primero métricas generales• Luego métricas específicas



• Adquisición de datos: ¿Dónde?– Rendimiento de la aplicación– Rendimiento del servidor de aplicaciones– Plataforma

– Dependencias externas



• Adquisición de datos: ¿Cómo?– APIs públicas– APIs propietarias– Instrumentación de código

– APIs de sistema y herramientas



• Instrumentación de código– Instrumentación ad hoc

• extraemos exactamente la información que necesitamos

– Instrumentación automática• no se modifica el código original• la herramienta puede instrumentalizar toda la aplicación• se puede modificar la cantidad de información recogida en

tiempo de ejecución• la instrumentación en bytecode es menos intrusiva• los datos se pueden recoger en un repositorio centralizado• muchas herramientas ofrecen una UI para presentar los

resultados gráficamente



• Impacto de la monitorización:– “El gato de Schrödinger”


Test de carga (1)

• Construcción de un test de carga:– “… conoce a tus usuarios …”

• Generación de cargas sintéticas– ordenar las peticiones a servicios por % de

tiempo– ampliar y reducir el tiempo de análisis para

modificar la granularidad del análisis– identificar variaciones de comportamiento por

hora, día, semana, mes y año


Test de carga (2)

• Generación de cargas sintéticas (2)– observar los bytes transferidos respecto la

media de tiempo de respuesta– identificar y categorizar el origen de las

peticiones (internas/externas/ubicación geográfica)

– % de peticiones correctamente servidas– % de errores HTTP– % de afiliación de usuarios y duración de sus

sesiones


Planificación de los test de carga

• Test unitario• Test con la aplicación integrada• Test de carga con la aplicación integrada• Test en preproducción• Test de carga en preproducción• Cálculo de los límites de capacidad


Teoría de tuning

• Wait-point tuning

• Ley de Amdahl

• Regla del 80-20

• Programación consciente de la arquitectura


Wait-point tuning (1)

• Buscar wait-points en la Arquitectura.• Abrir todos los wait-points.• Generar una carga representativa, equilibrada

e incremental contra el sistema.• Identificar el punto de saturación de los wait-

points.• Configurar todos los wait-points con la máxima

capacidad del wait-point más restrictivo.



• Wait-points típicos en entornos Web:– Heap– Web server thread pool– Servidor de aplicaciones o tier thread pool– Stateless session bean o business object

pool– Cache– Subsistema de persistencia


Ley de Amdahl

• Determina la ganancia del sistema cuando se mejora una de sus partes

– A: ganancia

– Am: ganancia de mejora del subsistema

– Fm: tiempo de mejor en el subsistema


Regla del 80-20 (1)

• El 80% de las mejoras en el rendimiento se obtienen mejorando el 20% del sistema


Regla del 80-20 (2)

• 80%:– Heap– Thread pools

– Connection pools

– Caches


Regla del 80-20 (3)

• 20%:– EJB pools– Precompilación de JSPs

– JMS

– SQL prepared statements

– Configuraciones avanzadas JDBC


JVM al detalle

• ¿Qué es?

• Ciclo de vida de una JVM

• Arquitectura

• Espacios de memoria

• Threads de aplicación

• Tipos de datos

• Class-loader


JVM: ¿Qué es?

• Cuando usamos el término JVM nos referiremos a:

– Especificación abstracta– Implementación concreta– Instancia de una implementación concreta

en ejecución


JVM: Ciclo de vida

• Ejecutar una única aplicación!!


JVM: Arquitectura


JVM: Memoria (1)

• Memoria persistente– Espacio de clases cargadas– Acceso compartido (thread-safe)– Inmersiones de eficiencia


JVM: Memoria (2)

• Heap– Almacenamiento de objetos instanciados– Espacio compartido (no thread-safe)– Garbage Collector

– Memory-leaks


JVM: Memoria (3)


JVM: Memoria (4)


JVM: Memoria (5)

• Heap: Garbage Collection– Lo bueno: él se encarga de que no se pieda

memoria– Lo malo: él se encarga de que no se pieda

memoria– Algoritmo dependiente de la implementación:

• Oracle / Sun JVM

• IBM JVM


JVM: Memoria (6)

• Oracle / Sun JVM Heap– Estrategia generacional

– Partición del heap en 4 areas– minor-garbage collection– major-garbage collection


JVM: Memoria (7)

• Oracle / Sun JVM Heap


JVM: Memoria (8)

• Oracle / Sun JVM Garbage Collector– Estado de los objetos del Heap:

• Alcanzables

• No alcanzables

– Grafo de dependencias– Nodos iniciales del grafo: root set

• Objetos estáticos

• Objetos creados por cualquier thread


JVM: Memoria (9)

• Oracle / Sun JVM Garbage Collector– root set

01: public class MyClass {02: public static final Integer n = new Integer( 10

);03: public Integer square( Integer i ) {04: int result = i.intValue() * i.intValue();05: return new Integer( result );06: }07: public static void main( String[] args ) {08: MyClass m = new MyClass();09: Integer i = new Integer( args[ 0 ] );10: i = m.square( i );11: }12:}

1 --2 n7 n, args8 n, args, m9 n, args, m, i3 n, args, m, i4 n, args, m, i, results5 n, args, m, i, results, anonymous Integer10 n, args, m, i11 n12 n


JVM: Memoria (10)

• Oracle / Sun JVM Garbage Collector

JVM: Memoria (11)

• Oracle / Sun JVM Garbage Collector


JVM: Memoria (12)

• Oracle / Sun JVM Garbage Collector– Minor-collections

• De centésimas a décimas de segundo• Concurrente

– Major-collections• De décimas a varios segundos

• Bloqueante


JVM: Memoria (13)

• Oracle / Sun JVM Garbage Collector– Parámetros específicos

• –XmxNNNm• –XmsNNNm• –XX:MaxNewSize=NNNm• –XX:NewSize=NNN• –XX:SurvivorRatio=n

– Ejemplo:-Xmx1024m -Xms1024m -XX:MaxNewSize=448m -XX:NewSize=448m -XX:SurvivorRatio=6


JVM: Memoria (14)



JVM: Memoria (15)



JVM: Memoria (16)

• IBM JVM Heap– Estrategia por bloques (>512bytes)

– Materia oscura– Único algoritmo de garbage collection

• mark & sweep

• compaction & refactoring-references– No todos los objetos se pueden refactorizar (JNI)

• Trigered garbage collection


JVM: Memoria (17)

• IBM JVM Heap– Parámetros recomendados:

• -Xms < -Xmx

• -Xmx ~= 130% de la carga máxima

• 30% < -Xminf < 40% del espacio libre• 20Mb < -Xmine < 50Mb• -Xgcpolicy:optavgpause

• -Xgcpolicy:gencon


JVM: Threads


JVM: Tipos de datos (1)

• Tipología:– Básicos– Referencias

• Especificación del lenguaje fuertemente definida

• Especificación de la JVM débilmente definida– word



• byte 8-bit CA2 (-27 to 27 - 1, inclusive)• short 16-bit CA2 (-215 to 215 - 1, inclusive)• int 32-bit CA2 (-231 to 231 - 1, inclusive)• long 64-bit CA2 (-263 to 263 - 1, inclusive)• char 16-bit Unicode caracter

• float 32-bit IEEE 754 precisión simple• double 64-bit IEEE 754 doble precisión• reference @heap, o null


JVM: Class-loader

• Tipos:– Bootstrap class-loader– User defined class-loader

• Responsabilidades:– Carga [class’ format a bytecode/nativecode]– Enlace con el código en ejecución.

• Verificar la consistencia léxica y sintáctica de la clase• Reservar espacio para la clase y sus atributos • Cambiar las referencias simbólicas a referencias directas del

espacio de memoria


Programación consciente de la JVM

• ArrayList & Vector• Evitar

– Object Cycling– News

• Usar– Tipos básicos– Clases estáticas sin estado

• No hacer tareas que ya hace el compilador



• ArrayList & Vector– Eficientes para

• Consultar• Actualizar

– Ineficientes para• Añadir• Quitar



• ArrayList & Vector– Añadir al principio (peor)– Añadir al final (mejor)– Predefinir el tamaño aumenta el rendimiento

• LinkedList– No usar acceso por índice– Insertar o quitar dependen de la distancia al

final de la lista– Estructura interna “sucia”


Java Experto: rendimientoseminarisempresa.fib.upc.edu/aulesempresa/2011/programes/Bitendia… ·...

Documents

Transcript of Java Experto: rendimientoseminarisempresa.fib.upc.edu/aulesempresa/2011/programes/Bitendia… ·...