Se presentará a continuación un resumen de los resultados de las pruebas de carga hechas sobre el equipo implantado en Facultad:
Bajo el supuesto de simular un caso extremo en una PyME se consideraron 50 usuarios activos, estableciendo conversaciones todos a la vez, añadiendo y eliminando contactos cada cierto tiempo, cambiando de estado de presencia. La herramienta de carga utilizada es el JabSimul. Con dicha herramienta se pueden configurar todas estas propiedades de las pruebas, dicha configuración es mediante archivo XML con los siguientes elementos:
user_names_generator (generados de nombres de usuario)
range: rango de usuarios (Ej test01, test02,....test50)
server: Nombre del servidor
connect: cada cuanto se conecta un usuario (en ms)
add_roster: cada que frecuencia (en ms) se debe añadir un usuario a lista de contactos hasta que el valor 'max_roster_count' sea alcanzado
del_roster: cada que frecuencia se borra un usuario de la lista de contactos
send_message: Mensaje a enviar (se utiliza mensaje de 50 caracteres)
range: rango de usuarios a los cuales puede un usuario enviar
change_status : cada cuanto tiempo (en ms ) el usuario cambia el estado de presencia
logout : cada cuanto se desconecta un usuario (en ms)
kill_connection: cada cuando una conexión es abortada
send_raw_bytes: envío de bytes aleatorios (ruido)
Para llegar a un valor coherente de largo de mensaje se realizaron conteos de palabras (promedio de 6 letras) de conversaciones en nuestros ambientes laborales y se tuvieron en cuenta datos del estudio hecho en el sistema de Mensajería de la empresa AT&T.
Según dicho estudio, en una conversación normal entre 2 usuarios que utilizan M.I. en una forma importante en un entorno laboral, los mensajes son de 12 palabras en promedio y cada mensaje es enviado cada 13 segundos.
Según nuestros conteos, los mensajes en promedio son de 7 u 8 palabras en promedio y se envían cada unos 20 segundos aprox..
Los valores para las pruebas del simulador fueron :
1 - Mensajes de largo 50 caracteres (8.3 palabras)
2 - En caso de la prueba de estabilidad, los mensajes eran enviados cada 7 segundos
En las pruebas de stress para medir retardo de mensajes y diferencia cuando estos son loggeados por Bandersnatch, los mensajes fueron enviados cada 15 segundos bajo el supuesto de que un usuario divida ese tiempo en leer un mensaje que le envía y contestar en 7 segundos otro mensaje de 50 caracteres.
Se realizo una prueba de carga de mas de 117 horas continuadas, y además se realizaron mediciones de trafico para estimar el uso de ancho de banda de red por usuario, las pruebas se realizaron sin registro de conversaciones con Bandersnatch.
Resultados:
prueba a las 63:54.39 hs de corrida
Conn stat: conns: total: 51 estabilished: 51
kills: total: 0 unexpected: 0
Messages: tot.sent: 3346120 tot.rcvd: 3346119
rcvd.offline: 0 rcvd.admin: 0
rcvd.normal: 3346119 fwd: 1673060 avg.time: 56 [ms]
diff check: 1 stability: 1
Roster: tot.adds: 43301 avg.time: 87 [ms]
tot.dels: 75353 avg.time: 98 [ms] glob_rost: 678
Presences: tot.sent: 390934 tot.rcvd: 3185947
Packets: created: 3935890 sent: 3935890
canceled: 0 in queues: 0
luego de 117:21.50 hs, se corta la prueba para realizar mediciones
Conn stat: conns: total: 51 estabilished: 51
kills: total: 0 unexpected: 0
Messages: tot.sent: 6144702 tot.rcvd: 6144702
rcvd.offline: 0 rcvd.admin: 0
rcvd.normal: 6144702 fwd: 3072351 avg.time: 55 [ms]
diff check: 0 stability: -2
Roster: tot.adds: 79370 avg.time: 90 [ms]
tot.dels: 138459 avg.time: 94 [ms] glob_rost: 688
Presences: tot.sent: 717944 tot.rcvd: 5859908
Packets: created: 7227220 sent: 7227220
canceled: 0 in queues: 0
Durante dichas las pruebas el servidor Jabberd utilizó un promedio de 30% de CPU y un 50 % de memoria.
El tráfico total de paquetes XML en los 7042 minutos fue de 4.3 GB aprox.
En promedio el ancho de banda que fue utilizado por los 50 usuarios fue de unos 85 kbps.
Cada usuario utilizo en promedio 1,7 kbps de ancho de banda.
Notamos que el servidor se comporta de excelente manera y que el consumo de recursos no es exagerado ni crece de forma significativa a lo largo de la prueba. También vemos que la utilización del recurso de Red no es de ninguna forma excesivo, una red de 10Mbps esta sobrada para soportar dicho servicio sin afectar la performance en la misma.
Aunque los tiempos de entrega de mensajes y operaciones del cliente son medidos en las siguientes pruebas simulando un entorno menos extremo de intercambio de mensajes, vemos en dicha prueba extrema que la entrega de cada mensaje demora en promedio 55 milisegundos.
Se realizaron 4 pruebas de aproximadamente 8 minutos con características similares a la prueba de estabilidad pero con la diferencia que dos de ellas fueron con intervalos más razonables adecuados a una dinámica más real de un entorno empresarial.
Repetimos que la diferencia básica es que el intervalo de espera de envío de mensajes por parte de los usuarios, que era cada 7 segundos en las pruebas de estabilidad pasa a ser de 15 segundos.
Consideramos razonable el contar con una demora de 15 segundos ya que es normal leer un mensaje de 50 caracteres en 7 segundos y responder con otro mensaje de ese tamaño en otros 7. La idea de esta prueba es ver las demoras que puede introducir el loggeo de conversaciones por Bandersnatch y cuanto afecta en la performance del servidor Jabber y del Hardware la activación de dicho registro.
Pruebas con valores de jabsimul idénticos a pruebas de estabilidad:
Resultado Prueba 1 – Sin Bandersnatch
Conn stat: conns: total: 51 estabilished: 51
kills: total: 0 unexpected: 0
Messages: tot.sent: 6546 tot.rcvd: 6545
rcvd.offline: 0 rcvd.admin: 0
rcvd.normal: 6545 fwd: 3273 avg.time: 55 [ms]
diff check: 1 stability: 0
Roster: tot.adds: 86 avg.time: 92 [ms]
tot.dels: 148 avg.time: 93 [ms] glob_rost: 693
Presences: tot.sent: 815 tot.rcvd: 6183
Packets: created: 8008 sent: 8008
canceled: 0 in queues: 0
Resultado Prueba 2 – Con Bandersnatch
Conn stat: conns: total: 51 estabilished: 51
kills: total: 0 unexpected: 0
Messages: tot.sent: 6578 tot.rcvd: 6514
rcvd.offline: 0 rcvd.admin: 0
rcvd.normal: 6514 fwd: 3257 avg.time: 72 [ms]
diff check: 64 stability: 1
Roster: tot.adds: 90 avg.time: 112 [ms]
tot.dels: 146 avg.time: 122 [ms] glob_rost: 694
Presences: tot.sent: 831 tot.rcvd: 6483
Packets: created: 8073 sent: 8072
canceled: 0 in queues: 1
Pruebas con valores adecuados a entorno más real empresarial
Resultado Prueba 3 – Sin Bandersnatch
Conn stat: conns: total: 51 estabilished: 51
kills: total: 0 unexpected: 0
Messages: tot.sent: 3048 tot.rcvd: 3047
rcvd.offline: 0 rcvd.admin: 0
rcvd.normal: 3047 fwd: 1524 avg.time: 53 [ms]
diff check: 1 stability: 1
Roster: tot.adds: 86 avg.time: 76 [ms]
tot.dels: 146 avg.time: 89 [ms] glob_rost: 705
Presences: tot.sent: 812 tot.rcvd: 6298
Packets: created: 4512 sent: 4512
canceled: 0 in queues: 0
Resultado Prueba 4 – con Bandersnatch
Conn stat: conns: total: 51 estabilished: 51
kills: total: 0 unexpected: 0
Messages: tot.sent: 3039 tot.rcvd: 3006
rcvd.offline: 0 rcvd.admin: 0
rcvd.normal: 3006 fwd: 1503 avg.time: 56 [ms]
diff check: 33 stability: 0
Roster: tot.adds: 87 avg.time: 95 [ms]
tot.dels: 145 avg.time: 102 [ms] glob_rost: 707
Presences: tot.sent: 817 tot.rcvd: 6504
Packets: created: 4499 sent: 4499
canceled: 0 in queues: 0
Notamos que en las pruebas realizadas con Bandersnatch, dicho componente utilizaba el 50% de CPU del sistema para realizar las tareas de registro y que en las pruebas de carga excesiva (dos primeras de este juego), se ve topeado el sistema por Bandersnatch , Jabberd, Jabbsimul y MySQL, de allí se puede ver la demora incrementada de 20 milisegundos en la entrega de mensajes, en las siguientes 2 pruebas adecuadas de carga extrema pero no excesiva, notamos que la entrega de los mensajes prácticamente no se ve afectada por el componente Bandersnatch.
Cabe destacar que tanto con o sin es sistema topeado por CPU, las operaciones de cambios en lista de contactos se ven demorados (en 20-30 ms), es de suponer que es por la utilización de ambos componentes (Jabberd y Bandersnatch) sobre el mismo recurso (MySQL ).
Si bien por falta de tiempo no se realizaron todos los tests necesarios para probar todos los límites y los detalles de la implantación (por ejemplo, prueba de escalabilidad sumando usuarios al servicio, pruebas utilizando motores de datos transaccionales o no en las Bases de Datos, etc.) , las pruebas realizadas las consideramos de gran importancia, ya que pusimos a prueba un servicio empresarial implementado en base a Software Open/Free en un hardware antiguo y se logró que el servicio estuviera: activo, bajo una situación de stress y estable durante aproximadamente 5 días. Además durante dicha prueba, la performance fue mas que satisfactoria.
Estudio del Open/Free (GNU/Linux) como plataforma de servicios de red en entornos empresariales
Daniel Caraballo - Mario Madera - Marcelo Odin
Tutor: Ariel Sabiguero Yawelak
2004 - 2005.