Hola a todos;
Estamos intentando migrar la red de telefonia analógica actual a un sistema de ToIP basado en openser. Tras montar el servidor y funcionar todo correctamente nuestro objetivo ahora es saber que carga puede soportar el servidor para poder dimensionar el servicio.
Para realizar las pruebas de carga, hemos escogido la herramienta SIPp, soft GNU que permite montar escenarios para estresar servidores SIP. Tras montar el escenario y realizar varias pruebas aún no hemos conseguido saturar el escenario, ya que antes que esto suceda tanto en el UAC como en el UAS, una vez alcanzada las 300 llamadas/s se sufren un gran número de retransmisiones a los pocos segundos.
Hemos cambiado los UAC y UAS a máquinas más potentes, pero el resultado es el mismo. Esto nos hace descartar que el problema sea derivado de falta de CPU y RAm ya que tanto el UAC, como el UAS como el proipo servidor no se llegan a saturar.
¿Alguien ha realizado pruebas de carga con SIPp obteniendo un resultado parecido? Si es así, ¿ a qué son debidas las retransmisiones y cómo se pueden evitar para poder conocer el limite de nuestro Openser Server? Si a alguien se le ocurre algún motivo que den lugar a estas retransmisiones, les agradeceria su coloboración.
Gracias de antemano
Hola,
Estamos intentando migrar la red de telefonia analógica actual a un sistema de ToIP basado en openser. Tras montar el servidor y funcionar todo correctamente nuestro objetivo ahora es saber que carga puede soportar el servidor para poder dimensionar el servicio.
Para realizar las pruebas de carga, hemos escogido la herramienta SIPp, soft GNU que permite montar escenarios para estresar servidores SIP. Tras montar el escenario y realizar varias pruebas aún no hemos conseguido saturar el escenario, ya que antes que esto suceda tanto en el UAC como en el UAS, una vez alcanzada las 300 llamadas/s se sufren un gran número de retransmisiones a los pocos segundos.
Hemos cambiado los UAC y UAS a máquinas más potentes, pero el resultado es el mismo. Esto nos hace descartar que el problema sea derivado de falta de CPU y RAm ya que tanto el UAC, como el UAS como el proipo servidor no se llegan a saturar.
¿Alguien ha realizado pruebas de carga con SIPp obteniendo un resultado parecido? Si es así, ¿ a qué son debidas las retransmisiones y cómo se pueden evitar para poder conocer el limite de nuestro Openser Server? Si a alguien se le ocurre algún motivo que den lugar a estas retransmisiones, les agradeceria su coloboración.
Hay por ahi varios documentos con pruebas de carga usando SIPp. Sobre las retransmisiones, ¿son porque el proxy no envía el 100 al UAC o es el UAC el que no se entera de que le llega el 100 y por eso retransmite?.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
Hola;
En primer lugar, gracias por tu contestación. La retransmisión se produce porque al UAC no le llega el 100 (No es el único punto donde se sufre retransmisiones) lo que hace que se vuelva a retransmitir hasta que el UAC se entera o bien la da como fallida.
Si bajamos la tasa pòr ejemplo a 200 llamadas/seg todo funciona correctamente sin ningún tipo de retrasnmisiones. Creemos que el tema anda en temas de TTL en el que el UAC no procesa el paquete antes de que se cumpla el TTL. Esto podria ser por satuarción del UAC ya que no le da tiempo a procesarlo (descartado ya que en ningún momento se encuentra sin RAM ni CPU) o bien porque el buffer de la tarjeta de red se encuentra lleno y el paquete se pierde. Esta es una de las problemáticas que hemos barajado como posible fuente de error, pero al igual es otra que no conseguimos identificar.
Saludos
S'està citant Jesus Rodriguez jesusr@voztele.com:
Hola,
Estamos intentando migrar la red de telefonia analógica actual a un sistema de ToIP basado en openser. Tras montar el servidor y funcionar todo correctamente nuestro objetivo ahora es saber que carga puede soportar el servidor para poder dimensionar el servicio.
Para realizar las pruebas de carga, hemos escogido la herramienta SIPp, soft GNU que permite montar escenarios para estresar servidores SIP. Tras montar el escenario y realizar varias pruebas aún no hemos conseguido saturar el escenario, ya que antes que esto suceda tanto en el UAC como en el UAS, una vez alcanzada las 300 llamadas/s se sufren un gran número de retransmisiones a los pocos segundos.
Hemos cambiado los UAC y UAS a máquinas más potentes, pero el resultado es el mismo. Esto nos hace descartar que el problema sea derivado de falta de CPU y RAm ya que tanto el UAC, como el UAS como el proipo servidor no se llegan a saturar.
¿Alguien ha realizado pruebas de carga con SIPp obteniendo un resultado parecido? Si es así, ¿ a qué son debidas las retransmisiones y cómo se pueden evitar para poder conocer el limite de nuestro Openser Server? Si a alguien se le ocurre algún motivo que den lugar a estas retransmisiones, les agradeceria su coloboración.
Hay por ahi varios documentos con pruebas de carga usando SIPp. Sobre las retransmisiones, ¿son porque el proxy no envía el 100 al UAC o es el UAC el que no se entera de que le llega el 100 y por eso retransmite?.
Saludos JesusR.
Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
La parte de los timers internos puede que no sea 100% fiable en situaciones de saturación. Estáis utilizando accesos a servicios externos (DNS,MySQL,RADIUS,perl....) en vuestra configuración?
Si el fichero de configuración no es demasiado complejo y tenéis tiempo, yo os aconsejaría probar la última versión de SER ya que la parte de timers está completamente reecha y puede que no sucedan esas retransmisiones. Por probar no perdéis nada...
suerte!
Samuel.
2008/3/10, Jose Molina Vizcaíno jose.molina-vizcaino@upcnet.es:
Hola a todos;
Estamos intentando migrar la red de telefonia analógica actual a un sistema de ToIP basado en openser. Tras montar el servidor y funcionar todo correctamente nuestro objetivo ahora es saber que carga puede soportar el servidor para poder dimensionar el servicio.
Para realizar las pruebas de carga, hemos escogido la herramienta SIPp, soft GNU que permite montar escenarios para estresar servidores SIP. Tras montar el escenario y realizar varias pruebas aún no hemos conseguido saturar el escenario, ya que antes que esto suceda tanto en el UAC como en el UAS, una vez alcanzada las 300 llamadas/s se sufren un gran número de retransmisiones a los pocos segundos.
Hemos cambiado los UAC y UAS a máquinas más potentes, pero el resultado es el mismo. Esto nos hace descartar que el problema sea derivado de falta de CPU y RAm ya que tanto el UAC, como el UAS como el proipo servidor no se llegan a saturar.
¿Alguien ha realizado pruebas de carga con SIPp obteniendo un resultado parecido? Si es así, ¿ a qué son debidas las retransmisiones y cómo se pueden evitar para poder conocer el limite de nuestro Openser Server? Si a alguien se le ocurre algún motivo que den lugar a estas retransmisiones, les agradeceria su coloboración.
Gracias de antemano
-- Jose Molina Vizcaíno
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Hola Samuel;
Pue si que se utilizan servicios externos y más concretamente BBDD MySQL pero el tema está en que el servidor no se encuentra saturado en ningún momento. De hecho a esta tasa de 300 llamadas/seg sólo se utiliza un 8% de CPU y sobra más de 1 GB de RAM.
Si bajamos la tasa pòr ejemplo a 200 llamadas/seg todo funciona correctamente sin ningún tipo de retrasnmisiones. Creemos que el tema anda en temas de TTL en el que el UAC no procesa el paquete antes de que se cumpla el TTL. Esto podria ser por satuarción del UAC ya que no le da tiempo a procesarlo (descartado ya que en ningún momento se encuentra sin RAM ni CPU) o bien porque el buffer de la tarjeta de red se encuentra lleno y el paquete se pierde. Esta es una de las problemáticas que hemos barajado como posible fuente de error, pero al igual es otra que no conseguimos identificar.
Gracias por tu consejo.
S'està citant samuel samu60@gmail.com:
La parte de los timers internos puede que no sea 100% fiable en situaciones de saturación. Estáis utilizando accesos a servicios externos (DNS,MySQL,RADIUS,perl....) en vuestra configuración?
Si el fichero de configuración no es demasiado complejo y tenéis tiempo, yo os aconsejaría probar la última versión de SER ya que la parte de timers está completamente reecha y puede que no sucedan esas retransmisiones. Por probar no perdéis nada...
suerte!
Samuel.
2008/3/10, Jose Molina Vizcaíno jose.molina-vizcaino@upcnet.es:
Hola a todos;
Estamos intentando migrar la red de telefonia analógica actual a un sistema de ToIP basado en openser. Tras montar el servidor y funcionar todo correctamente nuestro objetivo ahora es saber que carga puede soportar el servidor para poder dimensionar el servicio.
Para realizar las pruebas de carga, hemos escogido la herramienta SIPp, soft GNU que permite montar escenarios para estresar servidores SIP. Tras montar el escenario y realizar varias pruebas aún no hemos conseguido saturar el escenario, ya que antes que esto suceda tanto en el UAC como en el UAS, una vez alcanzada las 300 llamadas/s se sufren un gran número de retransmisiones a los pocos segundos.
Hemos cambiado los UAC y UAS a máquinas más potentes, pero el resultado es el mismo. Esto nos hace descartar que el problema sea derivado de falta de CPU y RAm ya que tanto el UAC, como el UAS como el proipo servidor no se llegan a saturar.
¿Alguien ha realizado pruebas de carga con SIPp obteniendo un resultado parecido? Si es así, ¿ a qué son debidas las retransmisiones y cómo se pueden evitar para poder conocer el limite de nuestro Openser Server? Si a alguien se le ocurre algún motivo que den lugar a estas retransmisiones, les agradeceria su coloboración.
Gracias de antemano
-- Jose Molina Vizcaíno
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Es difícil encontrar el bottleneck a distancia, yo te comentaba lo del acceso a servicios externos porque generalmente es el que más recursos consume y el que produce que los children que utilizen estos servicios se "bloqueen" por más tiempo. Si no tienes suficientes children, la petición de entrada se quedará en el buffer de recepción de openser hasta que alguno de estos children acaben la petición en curso y por tanto no podrá responder con el 100 y el UAC reenviará el INVITE.
Cuántos "children" tenéis puestos para procesar las llamadas? Puede que éstos se queden esperando una respuesta de la base de datos y no tienen porque estar saturando la máquina. Habéis configurado el parámetro max-connections del servidor MySQL?
A riesgo de equivocarme, no creo que se trate del TTL...si te refieres al campo del paquete IP éste no define tiempo sino nodos de la conexión y dudo que lleguéis a 0.
Otra cosa que puede pasar es que el SIPP no funcione correctamente con tasas altas...ahora no recuerdo exactamente qué pasaba pero creo recordar que no era especialmente fiable ya que tenía algún problemilla. Busca por ahi porque alomejor encuentras que tu sistema funciona todo bien y es la herramienta de testeo que falla.
Suerte, SAmuel
2008/3/10, Jose Molina Vizcaíno jose.molina-vizcaino@upcnet.es:
Hola Samuel;
Pue si que se utilizan servicios externos y más concretamente BBDD MySQL pero el tema está en que el servidor no se encuentra saturado en ningún momento. De hecho a esta tasa de 300 llamadas/seg sólo se utiliza un 8% de CPU y sobra más de 1 GB de RAM.
Si bajamos la tasa pòr ejemplo a 200 llamadas/seg todo funciona
correctamente sin ningún tipo de retrasnmisiones. Creemos que el tema anda en temas de TTL en el que el UAC no procesa el paquete antes de que se cumpla el TTL. Esto podria ser por satuarción del UAC ya que no le da tiempo a procesarlo (descartado ya que en ningún momento se encuentra sin RAM ni CPU) o bien porque el buffer de la tarjeta de red se encuentra lleno y el paquete se pierde. Esta es una de las problemáticas que hemos barajado como posible fuente de error, pero al igual es otra que no conseguimos identificar.
Gracias por tu consejo.
S'està citant samuel samu60@gmail.com:
La parte de los timers internos puede que no sea 100% fiable en
situaciones
de saturación. Estáis utilizando accesos a servicios externos (DNS,MySQL,RADIUS,perl....) en vuestra configuración?
Si el fichero de configuración no es demasiado complejo y tenéis tiempo,
yo
os aconsejaría probar la última versión de SER ya que la parte de timers está completamente reecha y puede que no sucedan esas retransmisiones.
Por
probar no perdéis nada...
suerte!
Samuel.
2008/3/10, Jose Molina Vizcaíno jose.molina-vizcaino@upcnet.es:
Hola a todos;
Estamos intentando migrar la red de telefonia analógica actual a un sistema de ToIP basado en openser. Tras montar el servidor y funcionar todo correctamente nuestro objetivo ahora es saber que carga puede soportar el servidor para poder dimensionar el servicio.
Para realizar las pruebas de carga, hemos escogido la herramienta SIPp, soft GNU que permite montar escenarios para estresar servidores SIP. Tras montar el escenario y realizar varias pruebas aún no hemos conseguido saturar el escenario, ya que antes que esto suceda tanto en el UAC como en el UAS, una vez alcanzada las 300 llamadas/s se sufren un gran número de retransmisiones a los pocos segundos.
Hemos cambiado los UAC y UAS a máquinas más potentes, pero el resultado es el mismo. Esto nos hace descartar que el problema sea derivado de falta de CPU y RAm ya que tanto el UAC, como el UAS como el proipo servidor no se llegan a saturar.
¿Alguien ha realizado pruebas de carga con SIPp obteniendo un resultado parecido? Si es así, ¿ a qué son debidas las retransmisiones y cómo se pueden evitar para poder conocer el limite de nuestro Openser Server? Si a alguien se le ocurre algún motivo que den lugar a estas retransmisiones, les agradeceria su coloboración.
Gracias de antemano
-- Jose Molina Vizcaíno
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
-- Jose Molina Vizcaíno Equip de Projectes Tecnològics UPCnet Edifici Màster's - Pedro i Pons, 9, 9è 08034 BARCELONA Telèfon: 93.405.43.60
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
sr-users-es@lists.kamailio.org
-
Jesus Rodriguez -
Jose Molina Vizcaíno -
samuel