Diferencia entre revisiones de «Performance De Aplicaciones»
(Página nueva: La performance en las aplicaciones es más que importante: no sólo puede mejorar (o perjudicar) la experiencia de un usuario, sino que puede hacer inviable (o inutilizable) a todo un...) |
|||
Línea 40: | Línea 40: | ||
==Ver también== | ==Ver también== | ||
* [[Prueba De Carga]] | * [[Prueba De Carga]] | ||
+ | |||
+ | [[Category:Performance]] | ||
+ | [[Category:Diseño De Software]] |
Revisión actual del 14:08 31 ago 2009
La performance en las aplicaciones es más que importante: no sólo puede mejorar (o perjudicar) la experiencia de un usuario, sino que puede hacer inviable (o inutilizable) a todo un desarrollo.
Medir la performance y realizar un análisis de los datos obtenidos no es una tarea trivial.
Contenido
Consejos
Saber qué esperar de nuestra aplicación
¿Cómo saber si nuestra aplicación funciona en tiempos aceptables, si los mismos no están definidos? Antes de realizar cualquier análisis de performance, es fundamental tener en claro qué esperar de estos resultados: debemos saber los tiempos esperados para cada una de las operaciones de nuestra aplicación.
El requerimiento debería tener ya indicados los tiempos aceptables para las funciones que tenga nuestro proyecto; si no los tiene, debemos exigirlos antes de avanzar! Hablando de lo cual...
Encarar la performance desde el principio del proyecto
Claro, a menos que luego querramos prender fuego todo. La performance requerida puede afectar a la solución planteada. Una solución viable con ciertos tiempos (y volúmenes) puede dejar de serlo con otro entorno. Y hablando de esto...
Probar performance en entorno de desarrollo no es indicativo de nada
¿Nuestra aplicación vuela en el entorno de desarrollo? ¿Y estamos contentos? No nos apuremos. El entorno de desarrollo no es en abosluto comparable al entorno productivo. El test final de performance debe realizarse contra un entorno productivo (o lo más parecido posible... y no, los "release" no sirven para esto).
Mover un gran volumen de datos es invitar al desastre
Si nuestro super-servicio necesita devolver (o procesar) miles y miles de registros, es una invitación perfecta a que ocurra algún problema. Desde insuficiente memoria hasta quilombos de performance, todo es posible.
Es siempre necesario analizar estos casos detenidamente, viendo la real necesidad de esta suerte de "migración" de datos a través del supuesto servicio.
Y por cierto, paginar millones de resultados tampoco es la solución mágica. Pero de serlo, no olvidar que...
Paginar por algún índice cuando sea posible
La paginación que provee Hibernate pagina utilizando el campo rownum de la base de datos. Sin embargo, en algunas consultas, esto puede ser sumamente ineficiente (llevando a que la demora aumente a medida que se piden páginas más alejadas).
Una buena solución es paginar por algún campo que sea índice de la tabla. Por ejemplo, es posible paginar los clientes por su código (id_cliente). Es decir, podría quedar:
Página 0: id_cliente 0 al 1000 Página 1: id_cliente 1001 al 2000 Página 2: id_cliente 2001 al 3000
Evidentemente, si existen "agujeros" en la columna "id_cliente" las páginas tendrán un tamaño variable, y podrán existir páginas sin datos. Sin embargo, la mejora en performance puede ser más que interesante.