viernes, 22 de agosto de 2008

Cherokee vs Apache2

Antes de empezar, visita los siguientes enlaces, donde encontrarás algunas recomendaciones antes de comenzar con la prueba:

Desde la red interna (sena):

http://10.3.240.246/wiki/BenchmarkAspectosImportantes

Desde la red externa (internet):


http://wiki.red-sena.net/BenchmarkAspectosImportantes


Desde la red interna (sena):

http://10.3.240.246/wiki/ErrorLimiteConcurrenciaPruebaBenchmark

Desde la red externa (internet):

http://wiki.red-sena.net/ErrorLimiteConcurrenciaPruebaBenchmark

Benchmark utilizado para la prueba

ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Caracteríticas del computador donde se encuentra alojada la página web:

Compaq nx9010
Procesador Intel Pentium 4 a 2.8 GHz
Memoria RAM de 512 MB
Disco duro de 60 GB
Sistema opertivo Linux Debian Etch 4.0
Cherokee 0.5.5
Apache2 2.2.3


Ejemplos de comandos usados:

katy:/etc/cherokee# ab -n700 -c300 -k http://127.0.0.1/

katy:/etc/apache2# ab -n700 -c300 -k http://127.0.0.1/



Aca le estoy enviando 700 requerimientos al servidor en grupos de 300 en 300 requerimientos al mismo tiempo. Lo que podriamos interpretar como si 300 usuarios le estan pidiendo abrir 700 requerimientos y le digo que que mantenga abierto el socket (-k).


Lo anterior lo realice para las pruebas completas, manteniendo constante C=300 y diciéndole siempre que mantenga abierto el socket (-k)



Prueba de rendimiento Cherokee

Cherokee llego al límite cuando -n valia 1700000 y observe lo siguiente:

katy:/etc/cherokee# ab -n1700000 -c300 -k  http://127.0.0.1/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 200000 requests
Completed 400000 requests
Completed 600000 requests
Completed 800000 requests
apr_socket_recv: Connection reset by peer (104)
Total of 996507 requests completed
katy:/etc/cherokee#



Despues que llego a su límite, reinicie el servicio y repetí la prueba, pero esta vez sin -k, osea que le estoy diciendo que cierre el socket.

Obtuve los siguientes resultados:


Gráfica 1 Cherokee: Número de requerimientos (n) vs 100% Longest Request




En esta gráfica observamos lo siguiente:

eje x: -n= Número de requerimientos
eje y: Tiempo en ms que demora en cargar una página al 100%
-c= Concurrencia, que siempre tuvo un valor de 300
Línea azul CON -k
Línea roja SIN -k


Los resultados eran los esperados, pues al decirle al servidor web que cerrara el socket (línea roja), le estaba diciendo que para cada requerimiento debia establecer una nueva conexión, lo que hacia mas lento el tiempo de respuesta. Por lo tanto, para este caso, el servidor es mas eficiente cuando usamos -k (mantener el socket abierto), pues asi él no tiene que establecer una nueva conexión para cada requerimiento.



Gráfica 2 Cherokee: Número de requerimientos (n) vs Request per second




A continuación, realizaré una prueba de rendimiento a los servidores web Cherokee y Apache2



eje x: -n= Número de requerimientos
eje y: Número de requerimientos por segundo
-c= Concurrencia, que siempre tuvo un valor de 300
Línea azul CON -k
Línea roja SIN -k


En el gráfico anterior podemos observar que cuando usamos -k el servidor es capaz de procesar mas requerimientos por segundo, pues como lo mencione anteriormente, no hay que establecer una nueva conexión para cada requerimiento, lo que hace mas rápido el proceso.

El servidor Cherokee es un servidor muy estable, que sometido a fuertes "presiones", es capaz de responder muy satisfactoriamente, incluso mejor que el Apache2, el cual observaremos a continuación:



Prueba de rendimiento Apache2


Observaciones

Las pruebas se realizaron con las mismas condiciones técnicas.

Se uso el mismo rango de valores que se utilizo para realizar la prueba de Cherokee.

Sólo se mostrará un gráfico (Número de requerimientos (n) vs Request per second).

El servidor web Apache2, llego a su límite cuando n valia 800.000

C=300



Gráfica 3 Apache2: Número de requerimientos (n) vs Request per second




Enlaces de interes



Apache2, apesar de ser uno de los servidores web mas usados actualmente, no es el mas eficiente, pues tiende a ser mas lento y no responde muy bien frente a fuertes "presiónes" como lo hace el Cherokee.



Gráfica 4: Comparación Cherokee vs Apache2


Observación:

Series con -k









Conclusiones


El servidor web Cherokee puede llegar a comportarse mejor frente a una gran avalancha de requerimientos, se recomienda usar -k para una mejor respuesta.

Cherokee puede procesar un mayor número de requerimientos que Apache2 y en un menor tiempo.

Apache2 es un servidor web muy usado, pero eso no quiere decir que sea el mejor.

jueves, 21 de agosto de 2008

Què es un Benchmark?

Wikipedia: "Un benchmark es una técnica que se utiliza para medir el rendimiento de un sistema o componente de un sistema"

http://es.wikipedia.org/wiki/Benchmark



Los siguientes son algunos parámetros que podemos usar al momento de realizar el Benchmark de rendimiento al servidor web, en este caso la prueba utilizada es la ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/:



-n requests Number of requests to perform
-c concurrency Number of multiple requests to make
-t timelimit Seconds to max. wait for responses
-p postfile File containing data to POST
-T content-type Content-type header for POSTing
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
-Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol Specify SSL/TLS protocol (SSL2, SSL3, TLS1, or ALL)
katy:/etc/cherokee#


Me enfocarè en tres aspectos: -k, -n y -c


-c
debe ser menor que -n, sino nos saldrá el siguiente error:

katy:/etc/cherokee# ab -n100 -c500 -k http://127.0.0.1/ ab: Cannot use concurrency level greater than total number of requests Usage: ab [options] [http[s]://]hostname[:port]/path



Es recomendable realizar cada prueba 3 veces y tomar siempre el valor mas pequeño, ejm:

katy:/etc/cherokee# ab -n2000 -c300 -k http://127.0.0.1/


Lo anterior lo realizamos 3 veces y tomamos el resultado mas pequeño, ejm: el Request per second mas pequeño.


Realizar la prueba completa con -k y luego sin -k para tener una mejor comparativa de resultados. Primero realizamos la prueba con -k y cuando terminemos, debemos reiniciar nuestro servidor web y luego realizar la prueba sin -k, sino reiniciamos, el servidor no toma los cambios.



Qué es -k:

Anteriormente http trabajaba de la siguiente manera: un usuario primero abria un socket(osea una conexion al servidor) y por él enviaba el request y esperaba la respuesta del servidor. Cuando el servidor respondia cerraba el socket y esperaba otros request.

Despues de http 1.1 se creo otro método que es keepalive, osea, -k, que es mantener abierto el socket.

La diferencia es:

El servidor , una vez responde no cierra el socket y lo deja abierto entre el usuario y el servidor por si el usuario hace mas requests, y eso hace que todo sea mas rápido por que solo tienen que crear una conexión, y no es necesario crear una para cada request. El servidor abre un socket con cada usuario que hace un request.

En conclusión, cuando usas esta opción (-k), le estas diciendo al servidor que deje el socket abierto, es por esto que se recomienda hacer pruebas con -k y sin -k para ver cómo se comporta el servidor web.


A continuación pongo ejemplos para entender mejor -n y -c:

Este es un ejemplo de comando que use en linux debian con la versión del benchmark mencionada anteriormente:


katy:/etc/cherokee#
ab -n10000 http://localhost/

Aca estoy enviando 10000 requerimientos al servidor, al no poner c le estoy diciendo que por defecto envie 1 al tiempo. Lo que podriamos interpretar como si un solo usuario enviara 10000 requerimientos al servidor web.



katy:/etc/cherokee# ab -n20000 -c16 -k http://localhost/

Aca le estoy diciendo que envie 20000 requerimientos al servidor en grupos de 16 en 16 requerimientos al mismo tiempo. Lo que podriamos interpretar como si 16 usuarios le estan pidiendo abrir 20000 requerimientos y que mantenga abierto el socket.


katy:/etc/cherokee# ab -n20000 -c16 http://localhost/



Este es casi igual al caso anterior, la diferencia es que le digo que no mantenga abierto el socket



El siguiente es un ejemplo que nos muestra cuàndo el servidor llegò a su lìmite:

katy:/etc/cherokee# ab -n2000000 -c300 -k http://127.0.0.1/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 200000 requests
Completed 400000 requests
Completed 600000 requests
Completed 800000 requests
apr_socket_recv: Connection reset by peer (104)
Total of 996507 requests completed
katy:/etc/cherokee#

martes, 19 de agosto de 2008

Error en límite de concurrencia. Prueba benchmark

Podemos forzar el servidor web incrementando el número de concurrencia con la opción -c, a la vez que aumentamos el número de requerimientos con -n.

Cuando hacemos esto se puede presentar el siguiente error:

katy:/etc/cherokee# ab -c 1100 -t 50 http://127.0.0.1/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/ Benchmarking127.0.0.1 (be patient)

socket: Too many open files (24)



El error anterior se puede corregir con el siguiente comando:

katy:/etc/cherokee# ulimit -n(número)

Este comando aumentará el límite del número de archivos abiertos para la sesión actual. Debe repetir este procedimiento cada vez que inicie una nueva sesión


lunes, 18 de agosto de 2008

MaxClientes y otras opciones en Apache2. Todo depende...

En esta parte del archivo de configuración del Apache2, podremos encontrar varias opciones que podremos ajustar, pero "todo depende de lo que queramos".

Primero, entramos al archivo de configuración del Apache2:

katy:/etc/apache2#

con ls visualizamos qué se encuentra dentro de apache2:

apache2.conf envvars mods-available ports.conf sites-enabled
conf.d httpd.conf mods-enabled sites-available

y editamos apache2.conf:

katy:/etc/apache2# nano apache2.conf

Buscamos las siguientes opciones que son las que nos interesan por el momento:

# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0

MaxClientes, StartServers, MinSpareServers y MaxSpareServers regulan la manera de atender peticiones. Apache funciona bien generalmente sin necesidad de modificar estos valores, pero caso contrario sucede cuando un sitio web necesita atender 250 peticiones simultáneas, necesitaremos aumentar el valor de MaxClientes, pero si tenemos un servidor web con poca memoria, necesitaremos disminuir este valor para evitar un mal rendimiento del servidor. No es recomendable que este valor supere los 256, pues podria generar inestabilidad del sistema.

MaxClientes: Si llegáramos a tener muchas peticiones en nuestro servidor web en un determinado momento, la memoria y el ancho de banda podrian no ser suficientes, es por eso que bajando el valor de MaxClientes que por defecto trae 150 a 100, por ejemplo, nuestro servidor web no se veria "alcanzado". Si, yo se que el servidor comenzaria a rechazar peticiones cuando llegue al límite de los 100, pero es mejor esto, pues le prestamos un mejor servicio a los clientes que se conecten y rechazaríamos a los demas clientes para asi darle un "respiro a nuestro servidor"

Si llegáramos a disminuir el valor de MaxClientes a valores muy bajos, el servidor podría bloquearse e incluso dejar de funcionar. La carga de la memoria será menor, pero la carga del sistema será mayor.

Max/MinSpareServers: Estos dos parámetros regulan el número de servidores que esperan peticiones.

El valor por defecto de MinSpareServers es 5 y el de MaxSpareServers es 10. Estos valores son suficientes generalmente. El número de MinSpareServers no debería ser elevado ya que crearía una carga muy alta, incluso cuando el tráfico estuviese bajo y no tuviéramos muchas peticiones.

StartServers: Maneja los procesos que serán creados al arrancar. El servidor Web crea y elimina dinámicamente servidores según el tráfico, no es necesario cambiar este valor. El servidor está configurado para arrancar 5 procesos en el arranque.










martes, 12 de agosto de 2008

Wake On Lan (Wol)

Es una tecnología que permite encender remotamente un computador desde otro computador que se encuentre en la misma Lan o en una Wan, configurando adecuadamente los routers.

Para permitir el encendido remoto, debemos habilitar la opción en el setup del computador que deseamos prender, generalmente esta opción la encontramos en Power management (en la BIOS) y requiere estar conectada como casi todas las redes, via ethernet y poseer ACPI (Interfaz Avanzada de Configuración y Energía) que es una tecnología que se encuentra en todas las fuentes ATX. Lo anterior para lograr que la computadora este escuchando por el puerto 9 de la interfaz de red. Las señales que espera recibir son de cualquier protocolo, aunque se usa UDP por el modelo de conexión que utiliza.

Qué necesitamos para que Wol funcione?

1. Que el hardware lo permita
2. Configurar el setup
3. Que el computador este apagado correctamente
4. Enviar la señal desde otro computador

Cómo funciona Wol?
Cuando el ordenador está apagado, las fuentes de alimentación ATX siguen alimentando a ciertas partes de la placa base permitiendo el Wake on Ring y la posibilidad de encender el PC sólo pulsando una tecla del teclado o que se encienda a una determinada hora.

Wake On Lan funciona en base a la dirección Mac del computador que deseamos encender, la cual podemos averiguar de las siguientes maneras:

En el mismo computador que deseamos encender (windows XP):


En la consola escribimos ipconfig /all, vemos que nos aparece una opción llamada dirección física como por ejemplo esta: 00-04-5C-50-6B-C8

Vamos a panel de control y hacemos click donde dice Conexiones de Red luego hacemos click encima de conexión de área local, click en soporte y luego click en detalles

En resumen, habilitamos la opción en el setup de la computadora que encenderemos y luego lo dejamos apagado. Descargamos un software en el computador desde donde encenderemos el otro pc y escribimos la dirección Mac del pc que será encendido, lo que enviara una señal al otro computador despertándolo y haciendo que este se encienda.

Algunos software recomendados:

Wake On Lan

Wake Up Lan

Esta es una tecnología que nos puede ayudar en muchas ocasiones si necesitamos acceder a un computador y no nos encontramos cerca de él, pero también puede ser muy peligrosa, pues cualquier persona que sepa que tenemos esta opción habilitada en nuestro computador y averigüe la dirección Mac, podría prenderlo y entrar a él, causar daños, extraer información, etc.

domingo, 10 de agosto de 2008

Algunos conceptos de DIRECTORIO ACTIVO


El Directorio Activo es un servicio de red que contiene toda la información acerca de los recursos de la red, como por ejemplo usuarios, archivos, impresoras, topología física, entro otros.


CARACTERÍSTICAS:

Delegación de control
Integración con kerberos
Integración con DNS
Administración centralizada
Dominio


ÁRBOL: Es una estructura jerárquica de dominios que comparten un sufijo DNS

BOSQUE:
Es un conjunto de árboles que no comparten el mismo sufijo DNS, como por ejemplo cuando se fusionan empresas y se quiere mantener el nombre de cada una.

UNIDAD ORGANIZATIVA: Son contenedores, osea que contienen objetos, como impresoras, carpetas compartidas, cuentas de usuario, otras unidades organizativas, etc.

DOMINIO: Es la estructura lógica del directorio activo, que almacena miles de objetos en el catálogo global dentro de un Controlador de dominio.

CONTROLADOR DE DOMINIO: Es un equipo con windows server 2000, 2003 o 2008 que almacena una réplica del directorio de dominio (Base de datos).

KERBEROS: Es un protocolo de autenticación usado en windows 2000 para el control de acceso, usado generalmente en redes no seguras.

viernes, 8 de agosto de 2008

Actualización del DNS con el DHCP en linux Debian

Instalamos los paquetes necesarios:

#apt-get install bind9

#apt-get install dhcp3-server


Entramos a la carpeta bind:

#cd /etc/bind/ ls

Vemos que se encuentra el archivo rndc.key. Copiamos esta llave en la siguiente ruta:

#cp /etc/bind/rndc.key /etc/dhcp3


Volvemos a bind:

#cd /etc/bind

Visualizamos los archivos dentro de bind, con ls y observamos que se encuentra el archivo named.conf y entramos a editarlo:

#pico named.conf


Agregamos la configuración de la llave que nos va a permitir actualizar dinámicamente el dns:

include "/etc/bind/rndc.key";


Configuramos la zona directa:

zone “katerine.com” {
type master;
file “/etc/bind/db.katerine”;



Para activar las actualizaciones con el DHCP ponemos lo siguiente:

notify yes;
allow-update {key "rndc-key";};
};



Configuramos la zona inversa:

zone “70.168.192.in-addr.arpa” {
type master ;
file “/etc/bind/db.192.168.70”;
notify yes;
allow-update {key "rndc-key";};
};


Guardamos los cambios.


Entramos a bind creamos las bases de datos de la zonas:

#cp db.127 db.192.168.70

#cp db.local db.katerine


Editamos el archivo db.katerine. En este archivo encontramos los nombres de los host y la dirección:

; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.thiney.com. root.katerine.com. (
20080801 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ) ; negative cache TTL
;
@ IN NS ns1.katerine.com.
@ IN A 192.168.70.3
@ IN MX 10 mx1.katerine.com.
www IN A 192.168.70.3
ftp IN CNAME www.
thiney IN A 192.168.70.10


Guardamos

Editamos el archivo db.192.168.70, la zona inversa es utilizada para resolver de direcciones IP a nombres.

;BIND reverse data file for broadcast zona
;
$TTL 604800
@ IN SOA ns1.katerine.com. root.katerine.com. (
20080801 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ) ; negative cache TTL
;
@ IN NS ns1.katerine.com.
2 IN PTR ns1.katerine.com.
10 IN PTR thiney.


Agregamos el servidor DNS en el resolv.conf.

#nano /etc/resolv.conf

Agregamos lo siguiente:

search katerine.com

nameserver 192.168.70.3 (dirección IP servidor DNS )


Reiniciamos:

#/etc/init.d/bind9 restart


Probamos:

#nslookup

Nos muestra lo siguiente:

> 192.168.70.3
Server: 192.168.70.3
Address: 192.168.70.3#53
3.70.168.192.in-addr.arpa name = ns1.katerine.com.