Entradas etiquetadas con dimensionamiento

Como elegir el mejor procesador para un servidor

¿Cual es el mejor procesador para un servidor (de aplicaciones)? No es una pregunta fácil. Para responderla, AODBC ha iniciado una serie de artículos sobre el tema. En esta primera parte da un apunte sobre el tema:

…para una granja de servidores web en un sitio de éxito puede que el nº de hilos por cpu gane importancia.

Esperemos que en las próximas entregas de la serie siga ahondando en este tema tan interesante. AODBC (a ojo de buen cubero) es uno de los blogs que sigo habitualmente, y te lo recomiendo para estar al día de todo el espectro TI.

Aprendiendo a usar Apache JMeter

Logo de Apache JMeter

Logo de Apache JMeter

En varias entradas, por ejemplo en esta, he comentado por encima el uso de Apache JMeter para medir el rendimiento de nuestro servidor de aplicaciones. Para dimensionar adecuadamente la memoria de nuestro servidor y optimizar los recursos de la maquina (física o virtual), el procedimiento es sencillo:

  1. Hacer una estimación de partida del consumo de memoria del servidor y sus aplicaciones.
  2. Realizar una prueba de carga contra las aplicaciones.
  3. Revisar los resultados de la prueba.
  4. Si creemos que es mejorable, modificar los parámetros de memoria del servidor y repetir.

Hace un tiempo ya escribí una entrada sobre como realizar la estimación de partida. En la entrada también se menciona el uso de JMX para supervisar el comportamiento del servidor mientras se realiza la prueba.

Para realizar la prueba de carga, la opción mas fácil es utilizar JMeter. Pero empezar a mirar la extensa documentación, la wiki o la referencia de funciones, puede resultar tedioso. Mi recomendación: descarga la aplicacion, descomprímela, y sin mirar nada mas, empieza directamente con el tutorial Recording Tests. Empezar por este tutorial es algo que seguramente no se te ocurriría, pero creo que seguir mi consejo te va a ahorrar mucho tiempo.

El tutorial tiene dos fases. En la primera, configuras JMeter para funcionar como proxy entre tu navegador y tu servidor de aplicaciones, de forma de va grabando tu navegación sobre la aplicación que quieres probar. En la segunda, ejecutas el test reproduciendo tu navegación y al acabar ves los resultados.

A partir de aquí te resultara mas sencillo buscar en la documentación de JMeter: ya sabrás para que sirve cada tipo de componente y podrás buscar aquello que necesites e ir mejorando tus tests para simular el comportamiento de los usuarios de forma mas realista.

Los 6 criterios principales a la hora de elegir servidor de aplicaciones

Armarios en un CPD. Fuente: Wikipedia.

Armarios en un CPD. Fuente: Wikipedia.

Hay ocasiones en las cuales se plantea la necesidad de elegir un servidor de aplicaciones para albergar una nueva aplicación. Según a que departamento de la organización pertenezcamos, tenderemos a primar unos criterios sobre otros. Si entras habitualmente en este blog, seguramente tendrás el punto de vista del administrador de sistemas. Sin embargo, hay que recordar que el departamento de TI debe estar siempre alineado con el negocio. Veamos ahora los criterios en orden de importancia.

Los 6 criterios

1. Necesidades de la aplicación

A veces la elección del servidor a utilizar empieza con la toma de requisitos de la aplicación. En otras la simple elección de una aplicación nos ata a determinado servidor: Zimbra, por ejemplo, viene acompañado de un Jetty configurado a su gusto. Las necesidades de la aplicación (y de la organización) van por delante de cualquier otra consideración. Pero, como veremos mas adelante, no hay que confundir las necesidades de corto y de largo plazo. Tampoco hay que confundir las necesidades de la aplicación con las preferencias de tal o cual departamento.

2. Ecosistema software del servidor de aplicaciones

Este criterio esta muy relacionado con el anterior. En ocasiones, debido a la naturaleza de la aplicación se hace necesario la utilización de una biblioteca o componente perteneciente a un servidor de aplicaciones concreto o cuya integración esta optimizada para un servidor. Por ejemplo, si queremos realizar una aplicación de lógica de negocio, con reglas, flujos de trabajo y planificación automática y la plataforma Drools de la comunidad JBoss es la que mas se adapta a nuestras necesidades, seguramente nos compense utilizar JBoss EAP o WildFly.

3. Experiencia de los desarrolladores

Hace ya un montón de años, en la carrera, le escuche a un profesor de Ingeniería del Software que el software no podía cumplir con las tres B: bueno, bonito y barato. Puedes tenerlo bueno y bonito pero no barato. O bueno y barato pero no sera bonito. También puedes tenerlo bonito y barato pero entonces no sera bueno. Sea como sea, lo principal es que sea bueno. Para eso es necesario que los desarrolladores sean buenos y tengan experiencia. En este caso, me refiero tanto a que tengan experiencia con la tecnología de desarrollo como con el servidor de aplicaciones. Elegir un servidor de aplicaciones porque es el que viene integrado con el IDE, no es un criterio valido a priori: no tienen experiencia con el servidor ni en la tecnología, sino con el IDE.

4. Base de servidores instalada

Tener una gran variedad de servidores de aplicaciones instalados, o en sus diferentes versiones, puede llegar a convertirse en un problema serio. Se dificulta el mantenimiento, aumentan los tiempos para identificar errores, se complica mantener actualizados los servidores… si solo se tienen en cuenta los tres primeros criterios a la hora de elegir el servidor, la organización tiene un problema. Se esta poniendo en peligro la consecución de los objetivos a largo plazo para cumplir los que tenemos a corto plazo. Efectivamente, una aplicación se termina antes y mejor si solo se tienen en cuenta los aspectos del desarrollo. Pero si repetimos esto cada vez, con cada aplicación, y nuestro parque de servidores crece sin control, tarde o temprano no habrá manera de administrarlos. Cuando la aplicación principal de la organización se pare, y con ella la organización entera, ya sera tarde.

5. Experiencia de los administradores de sistemas

Seguramente te sorprenderás de ver este criterio tan abajo. En mi opinión, que puede ser tan subjetiva como la de cualquiera, un mal administrador puede tener funcionando una buena aplicación pero un buen administrador lo tendrá muy difícil para mantener arriba una aplicación deficiente, aunque lo lograra sin ninguna duda. Si la base de servidores se mantiene razonablemente estable, tendrán tiempo de formarse en los nuevos servidores que vayan llegando y en las nuevas versiones de los existentes. Pero atención: que los administradores sean adaptables no quiere decir que se deba abusar de ello. Mantener los servicios funcionando es trabajo del administrador, pero responsabilidad de toda la organización.

6. Rendimiento del servidor de aplicaciones

A pesar de que podría pensarse que el rendimiento del servidor debe ser el criterio principal para su elección, creo que esto es un error. En este momento prácticamente todos los servidores de aplicaciones tienen un rendimiento suficiente para no tener problemas con su ejecución. Seria un caso distinto si el rendimiento del servidor fuera una necesidad de la aplicación: en ese caso estaríamos en el primer criterio. Por ejemplo: una base de datos NoSQL puede tener un mayor rendimiento que una relacional en determinados casos, pero no por eso instalamos todos nuestros servicios con bases de datos NoSQL. Ademas, el rendimiento no es un criterio absoluto, sino relativo. Dependerá del escenario.

Conclusión

Seguramente te haya llamado la atención que los criterios de la parte de sistemas estén relegados a las ultimas posiciones, por detrás de criterios de desarrollo. Lógicamente, si eres el responsable de sistemas, tu labor sera defender el trabajo de tus técnicos, pero no pierdas de vista para qué te contrataron. Como decía al principio, la lista esta confeccionada para cumplir con los objetivos de la organización, no con mis preferencias.

¿Y tu estas de acuerdo? ¿Añadirías algún criterio mas?

Como calcular el consumo de memoria de un servidor de aplicaciones

Logo de Java

Logo de Java

En ocasiones nos resultara necesario conocer cuanta memoria RAM esta consumiendo alguno de nuestros servidores Java. Conocer este consumo nos permite, por ejemplo, saber si podemos instalar otro servidor en la misma máquina: por nada del mundo queremos que la maquina utilice la swap. En el momento en que la memoria de intercambio entra por la puerta, el rendimiento salta por la ventana.

En realidad no es necesario conocer el consumo con exactitud en un determinado momento. Lo que necesitaremos es la cota máxima. Debemos asegurar que la máquina no utilice memoria swap en el peor de los escenarios, por lo cual controlaremos que la suma de la memoria utilizada por los servidores de aplicaciones instalados y el sistema operativo nunca supere a la cantidad de memoria RAM de la máquina.

Para calcular la cota máxima de consumo, sumaremos los siguientes elementos:

Heap maximo

Este valor lo obtendremos del parámetro -Xmx de la configuracion del JDK. En el caso de que no hayamos fijado dicho máximo en la configuración, tomaremos el valor máximo por defecto. El valor por defecto, desde la versión del JDK 6u18, se calcula principalmente a partir de la memoria física disponible con algunas otras condiciones que podéis ver en las release notes del JDK mencionado. Básicamente sera un cuarto de la memoria física con un limite de 1G para el JDK de 32 bits y 32G para el JDK de 64 bits.

PermGen maximo

Este segundo valor será el indicado por el parametro -XX:MaxPermSize. Como en el caso anterior, si no lo hemos configurado, se utilizara el valor por defecto: 64M por lo general. No es raro encontrar aplicaciones que consumen mucho mas, pero aunque no fuera el caso, debemos añadir el PermGen máximo a la suma.

Máxima cantidad de memoria utilizada por procesos

Cada vez que arrancamos un servidor de aplicaciones, se inician una serie de procesos: el número dependera del servidor de aplicaciones que usemos y su configuración, de las aplicaciones que tengamos desplegadas y de la carga del servidor. Así que necesitaremos saber cuantos procesos se utilizan y cuanto ocupa la pila de cada proceso.

Empecemos por conocer el numero de procesos utilizados. Esto nos resultará muy sencillo si tenemos monitorizado nuestro servidor de aplicaciones por JMX. Veamos una captura de jconsole:

Comportamiento de Tomcat durante la prueba

Comportamiento de Tomcat durante una prueba (pulsa para agrandar)

Fijándonos en la parte superior derecha, veremos un gráfico con el titulo Threads. En el gráfico podemos ver que el servidor utiliza unos 40 procesos.

Ahora veamos como obtener cuanta memoria utiliza cada proceso. Esta cantidad se define con el parámetro -Xss y si no lo tenemos definido, los valores por defecto son 320K para la maquina de 32 bits y 1024k para la de 64. Por lo cual tendremos que:

Máxima memoria de procesos = Número de procesos * Memoria de cada proceso

Conclusión

Una vez que hemos obtenido todos los valores, solo necesitamos hacer una suma para conocer la cota máxima de consumo de nuestro servidor:

Heap máximo + PermGen máximo + Máxima memoria de procesos

De ahora en adelante, ya podrás calcular si puedes instalar otro servidor en una de tus maquinas o asegurarte de que hay RAM disponible para aumentar el Heap de alguno de ellos en caso de necesitarlo.

Instalando el JDK en servidores en la nube

Hace unos meses publique una entrada explicando la instalación del JDK en linux. Ese articulo lo escribí teniendo en mente el bajo precio de la memoria RAM y su abundancia en la mayor parte de entornos actuales. Sin embargo no contemplaba un escenario que esta cogiendo fuerza por momentos: la computación en la nube. Con un enfoque iaas, contratamos maquinas virtuales a un proveedor y este nos factura en función del dimensionamiento y/o del consumo. En estos casos, es muy importante la optimización de los recursos para reducir los costes todo lo posible. Así que he editado el articulo para contemplar estos casos. Creo que ha quedado mucho mas completo y espero que sea de utilidad.

Ir arriba