Friday, December 6, 2013

Elegir el tamaño de una VM para desarrollo o pruebas

Al crear una nueva VM para nuestro ambiente de desarrollo o pruebas siempre surge la duda de cual es el tamaño apropiado, a fin de balancear costos con capacidad de proceso.

Lógicamente, mayor capacidad de proceso significa mayor costo. Si analizamos la tabla de precios por hora publicada en el sitio de Windows Azure es muy considerable el salto que existe entre una instancia Extra Small a una instancia Small.


Esta diferencia de cierta forma es justificada debido que estamos pasando de una instancia donde el procesador es compartido entre varias instancias, a una instancia con procesador propio y mas del doble de memoria. No obstante, resulta muy difícil determinar a primera vista cual es la opción que mejor balance nos dará entre costo y desempeño.

Sucede que estamos acostumbrados a que los equipos en los que habitualmente desarrollamos tienen una potencia mucho mayor a lo expresado en la tabla: hoy en día cualquier desarrollador cuenta con 8gb de memoria y cuatro procesadores en su notebook. Sin embargo tenemos que tener en cuenta no son parámetros comparables.

Las VMs generadas en Windows Azure se encuentran muy optimizadas para realizar específicamente las tareas de procesamiento que necesitamos, dejando de lado muchos "lujos" que nos damos en nuestra notebook o computador de escritorio y que hacen uso intensivo de los recursos del ordenador. Así mismo ocurre con el hardware en donde se encuentran virtualizadas esos computadores. Por lo que el rendimiento de una máquina pequeña en Windows Azure puede llegar a sorprendernos (para bien), de acuerdo a nuestra percepción (distorsionada) de lo que siginifican 768Mb de memoria RAM.

Esta percepción distorsionada puede collevar implicancias mucho mayores.

Imaginemos la siguiente situación. Nuestra aplicación requiere una consulta de base de datos de cierta complejidad donde es necesario relacionar datos de varias tablas mediante inner joins. En principio vemos que la consulta tiene un buen desempeño en nuestro ambiente de desarrollo (ej. un notebook I7 con 8Gb), aún cuando observando que la cantidad de datos sería similar a lo que esperaríamos tener en producción.

Esta percepción es muy engañosa ya que el optimizador de queries de Sql Server puede elegir caminos muy diversos dependiendo de los recursos con los que cuenta el sistema. En el caso de nuestra poderosa notebook, puede ocurrir que determinadas falencias en nuestro modelo queden ocultas detrás de tanta potencia (ejemplo, carencia de ciertos índices clave).

Una buena forma de descubrir estas falencias es utilizar un ambiente de pruebas pequeño. 

De esta forma rápidamente saltarán a la vista las funcionalidades de nuestra aplicación que podrían ser mejoradas desde el punto de vista de desempeño (ej. consultas lentas, bloqueos, páginas pesadas, etc.), dándonos la oportunidad de investigar y reimaginar la forma en que resolvemos determinados problemas con el objetivo de lograr un desempeño óptimo.

Conclusiones.

  • No subestimar el poder de una máquina pequeña, muchas veces una instancia Extra Small es mas que suficiente para nuestro ambiente de pruebas o desarrollo
  • Siempre tenemos la oportunidad de agregar mas capacidad en el futuro sin que esto signifique un impacto en la aplicación (esa es la gran ventaja de Windows Azure)
  • Un ambiente sobre-dimensionado puede llevarnos a sobre-utilizar recursos 
  • Un ambiente restringido en recursos nos facilita identificar las oportunidades de mejora de desempeño y a la larga nos vuelve mas creativos a la hora de hacer nuestra aplicación mas performante.




 












No comments:

Post a Comment