Son las anotaciones que hice ayer en pizarra en la clase de prácticas. La curiosidad es que por error usé un rotulador permanente :| por lo que no se podrán quitar de esa (pobre) pizarra.
jueves, 10 de abril de 2014
Anotaciones (imborrables) en pizarra de la Práctica 4
Son las anotaciones que hice ayer en pizarra en la clase de prácticas. La curiosidad es que por error usé un rotulador permanente :| por lo que no se podrán quitar de esa (pobre) pizarra.
martes, 8 de abril de 2014
Resumen del Tema 5: Medir prestaciones
En este tema hemos estudiado las metodologías y métricas principales para medir las prestaciones de nuestro sistema web, tanto de los servidores finales como de los dispositivos de balanceo.
El objetivo es comprobar si nuestro sistema cumple unos mínimos requisitos de rendimiento, y para ello debemos aplicar una metodología de test de prestaciones para detectar posibles problemas de rendimiento.
Querremos detectar con antelación posibles problemas de rendimiento y/o de degradación de recursos.
Así pues, y según el sitio web, proponemos usar las siguientes métricas:
Aunque el tema ha sido más extenso, hemos visto que existe un límite de tráfico de red suficientemente alto que produce una degradación grave en las prestaciones:
+00.16.48.png)
En unos casos ese límite es más fácil de alcanzar que en otros, pero llegado a ese límite los tiempos de respuesta en las conexiones HTTP se degradan completamente, haciendo imposible la conexión. Estas degradaciones en las prestaciones se deben a los cuellos de botella.
Por último, para realizar estas pruebas y tests, podemos usar diferentes tipos de software. Esta última parte está estrechamente relacionada con la Práctica 4. En esta penúltima práctica utilizaremos Apache benchmark, httperf y openwebload.
Concretamente los contenidos estudiados en el Tema 5 han sido:
El objetivo es comprobar si nuestro sistema cumple unos mínimos requisitos de rendimiento, y para ello debemos aplicar una metodología de test de prestaciones para detectar posibles problemas de rendimiento.
Querremos detectar con antelación posibles problemas de rendimiento y/o de degradación de recursos.
Así pues, y según el sitio web, proponemos usar las siguientes métricas:
- conexiones por segundo: Hace referencia al número de conexiones de entrada que cierto dispositivo puede manejar por segundo. Es un factor determinante, ya que abrir y cerrar conexiones HTTP resulta muy costoso.
- número total de conexiones concurrentes: Métrica para determinar cuántas sesiones de usuario TCP puede manejar el balanceador al mismo tiempo. Está limitada por la memoria o el procesador del dispositivo.
- rendimiento (en bits por segundo): Hace referencia a la velocidad a la que el balanceador maneja y pasa el tráfico. Se mide en bits por segundo. Es combinación de las variables "tamaño del paquete" y "paquetes por segundo".
Aunque el tema ha sido más extenso, hemos visto que existe un límite de tráfico de red suficientemente alto que produce una degradación grave en las prestaciones:
En unos casos ese límite es más fácil de alcanzar que en otros, pero llegado a ese límite los tiempos de respuesta en las conexiones HTTP se degradan completamente, haciendo imposible la conexión. Estas degradaciones en las prestaciones se deben a los cuellos de botella.
Por último, para realizar estas pruebas y tests, podemos usar diferentes tipos de software. Esta última parte está estrechamente relacionada con la Práctica 4. En esta penúltima práctica utilizaremos Apache benchmark, httperf y openwebload.
Concretamente los contenidos estudiados en el Tema 5 han sido:
- Introducción
- Conexiones por segundo
- Número de conexiones concurrentes
- Rendimiento, en bits por segundo
- Tipos de tráfico
- Límite en las prestaciones
- Software
- Apache benchmark
- httperf
- OpenWebLoad
jueves, 3 de abril de 2014
Práctica 4: medida de prestaciones en servidores web
En la práctica 4 que comenzaremos la semana próxima (del 7 al 11 de abril) y continuaremos tras la Semana Santa, utilizaremos varias herramientas para comprobar el rendimiento de servidores web.
Disponemos de varias herramientas, tanto de línea de comandos como con interfaz gráfica:
Estas herramientas permiten comprobar el rendimiento de cualquier servidor web (Apache, MS Internet Information Services -IIS-, nginx, Cherokee, Tomcat, lighttpd, thttpd, etc), y se suelen usar para comprobar el rendimiento del hardware, software o de alguna modificación que le hayamos hecho.
Usar Apache Benchmark (ab)
ab no simula con total fidelidad el uso del sitio web que pueden hacer los usuarios habitualmente. Pide la misma página repetidamente. Sin embargo, los usuarios reales no solicitan siempre la misma página, por lo que las medidas dan una idea aproximada del rendimiento del sitio, pero no reflejan el rendimiento real.
Va bien para testear cómo se comporta el servidor antes y después de modificar cierta configuración. Puesto que tenemos los datos del "estado base", podemos comparar cómo afecta una nueva configuración.
Debemos ejecutar el benchmark en otra máquina diferente a la que hace de servidor web. Ambos procesos no deben consumir recursos de la misma máquina (veríamos un menor rendimiento). Así pues, estando las tres máquinas de nuestra granja web en ejecución, desde otro máquina diferente (ya sea la anfitriona u otra máquina virtual) haremos las baterías de ejecuciones pidiendo páginas a la dirección IP del balanceador:
+00.15.29.png)
Cada vez que ejecutemos el test obtendremos resultados ligeramente diferentes. Esto es debido a que en el servidor hay diferente número de procesos en cada instante, y además la red puede encontrarse más sobrecargada en un momento que en otro.
Para ejecutar el benchmark ab usamos la sintaxis:
ab -n 1000 -c 5 http://maquina.com/prueba.html
Nos quedaremos con las medidas de "Time taken for tests", "Failed requests", "Requests per second", "Time per request".
Una vez que terminemos las baterías de ejecuciones con la granja web, debemos repetirlas (las mismas cargas) contra una sola de las máquinas servidoras finales (p.ej. la IP de la máquina1). Así esperamos poder comparar cómo se comporta una sola máquina frente a la granja web ante diferentes cargas.
Usar httperf
httperf es una herramienta para medir el rendimiento de sitios web desarrollada en los laboratorios de investigación de Hewlett-Packard.
La sintaxis de ejecución es:
httperf --server maquina.com --uri /prueba.html --port 80 --num-conn 5000 --num-call 10 --rate 200 --timeout 5
En esa orden estamos haciendo un test del servidor maquina.com, puerto 80. httperf pedirá, de forma repetida, la página llamada "prueba.html" abriendo un total de 5000 conexiones TCP para hacer con cada una de ellas varias peticiones HTTP (implica hacer la petición y esperar la respuesta). Hará 10 peticiones por conexión, y las hará a 200 conexiones por segundo (implica 2000 peticiones/seg). Establece un timeout (número de segundos que el cliente esperará respuesta) tras el cual considerará que la llamada ha fallado.
En este caso nos quedaremos con las medidas de "Request rate" y "Errors".
Tanto en esta herramienta como en la siguiente, repetiremos la forma de proceder que hemos explicado para el ab. Los valores que obtengamos con ab, httperf u OpenWebLoad no son comparables, ya que se trata de métricas diferentes, y obtenidas con software que trabaja de muy diferente forma.
Usar OpenWebLoad
OpenWebLoad es otra herramienta de línea de comandos para medir el rendimiento de servidores web:
openload -l 20 http://maquina.com 10
El programa recibe varios parámetros, muy similares a los de las herramientas anteriores:
Disponemos de varias herramientas, tanto de línea de comandos como con interfaz gráfica:
- Apache Benchmark
- httperf
- OpenWebLoad
- The Grinder
- OpenSTA
- JMeter
Estas herramientas permiten comprobar el rendimiento de cualquier servidor web (Apache, MS Internet Information Services -IIS-, nginx, Cherokee, Tomcat, lighttpd, thttpd, etc), y se suelen usar para comprobar el rendimiento del hardware, software o de alguna modificación que le hayamos hecho.
Usar Apache Benchmark (ab)
ab no simula con total fidelidad el uso del sitio web que pueden hacer los usuarios habitualmente. Pide la misma página repetidamente. Sin embargo, los usuarios reales no solicitan siempre la misma página, por lo que las medidas dan una idea aproximada del rendimiento del sitio, pero no reflejan el rendimiento real.
Va bien para testear cómo se comporta el servidor antes y después de modificar cierta configuración. Puesto que tenemos los datos del "estado base", podemos comparar cómo afecta una nueva configuración.
Debemos ejecutar el benchmark en otra máquina diferente a la que hace de servidor web. Ambos procesos no deben consumir recursos de la misma máquina (veríamos un menor rendimiento). Así pues, estando las tres máquinas de nuestra granja web en ejecución, desde otro máquina diferente (ya sea la anfitriona u otra máquina virtual) haremos las baterías de ejecuciones pidiendo páginas a la dirección IP del balanceador:
Cada vez que ejecutemos el test obtendremos resultados ligeramente diferentes. Esto es debido a que en el servidor hay diferente número de procesos en cada instante, y además la red puede encontrarse más sobrecargada en un momento que en otro.
Para ejecutar el benchmark ab usamos la sintaxis:
ab -n 1000 -c 5 http://maquina.com/prueba.html
- -n 1000 => se solicita mil veces en total la URL
- -c 5 => se hacen peticiones de 5 en 5 (concurrencia)
Nos quedaremos con las medidas de "Time taken for tests", "Failed requests", "Requests per second", "Time per request".
Una vez que terminemos las baterías de ejecuciones con la granja web, debemos repetirlas (las mismas cargas) contra una sola de las máquinas servidoras finales (p.ej. la IP de la máquina1). Así esperamos poder comparar cómo se comporta una sola máquina frente a la granja web ante diferentes cargas.
Usar httperf
httperf es una herramienta para medir el rendimiento de sitios web desarrollada en los laboratorios de investigación de Hewlett-Packard.
La sintaxis de ejecución es:
httperf --server maquina.com --uri /prueba.html --port 80 --num-conn 5000 --num-call 10 --rate 200 --timeout 5
En esa orden estamos haciendo un test del servidor maquina.com, puerto 80. httperf pedirá, de forma repetida, la página llamada "prueba.html" abriendo un total de 5000 conexiones TCP para hacer con cada una de ellas varias peticiones HTTP (implica hacer la petición y esperar la respuesta). Hará 10 peticiones por conexión, y las hará a 200 conexiones por segundo (implica 2000 peticiones/seg). Establece un timeout (número de segundos que el cliente esperará respuesta) tras el cual considerará que la llamada ha fallado.
En este caso nos quedaremos con las medidas de "Request rate" y "Errors".
Tanto en esta herramienta como en la siguiente, repetiremos la forma de proceder que hemos explicado para el ab. Los valores que obtengamos con ab, httperf u OpenWebLoad no son comparables, ya que se trata de métricas diferentes, y obtenidas con software que trabaja de muy diferente forma.
Usar OpenWebLoad
OpenWebLoad es otra herramienta de línea de comandos para medir el rendimiento de servidores web:
openload -l 20 http://maquina.com 10
El programa recibe varios parámetros, muy similares a los de las herramientas anteriores:
- El tiempo en segundos que queremos ejecutarlo (opción -l).
- La URL de la página en el servidor.
- El número de clientes simultáneos que simularemos (es un parámetro opcional y el valor por defecto es 5).
miércoles, 2 de abril de 2014
Tema 4: Balanceo de carga
Lo comenzamos justificando el paso de los grandes mainframes a las tecnologías basadas en balanceo de carga:
+00.12.48.png)
Este tema nos ha llevado tres semanas, y hemos visto los siguientes puntos:
1. Introducción
2. Funcionamiento básico de un servidor
3. Conceptos del balanceo de carga
4. Otras tecnologías
5. Estructura de la red
6. Algoritmos de balanceo de carga
7. Balanceo con dispositivos hardware
8. Balanceo de carga global
9. Ejemplo 1
10. Ejemplo 2
11. Ejemplo 3
12. Futuro de las tecnologías de balanceo
13. Resumen y conclusiones
Las dos partes más importantes han sido los algoritmos de balanceo de carga estudiados y la tecnología de balanceo de carga global.
Los algoritmos de balanceo estudiados han sido:
- balanceo basado en turnos (round-robin)
- balanceo basado en el menor número de conexiones
- balanceo basado en ponderación
- balanceo basado en prioridad
- balanceo basado en tiempo de respuesta
- combinación de los algoritmos de tiempo de respuesta y menor número de conexiones
En cuanto a la implementación del GSLB, en la clase de ayer estudiamos las siguientes opciones:
- Uso del DNS
- Redirección HTTP
- GSLB basado en DNS
- GSLB usando protocolos de enrutamiento
Suscribirse a:
Entradas (Atom)