Desempenho do Asterisk na Versão 1.4.11

Fonte original: Extraído do site http://www.transnexus.com, da empresa Transnexus, em Novembro 2007.

Depois de receber bastante feedback positivo sobre o teste de desempenho realizado com o OpenSER. Voltamos-nos à atenção para o Asterisk. Sempre tem havido um debate ativo a cerca da escalabilidade do Asterisk por isso decidimos por nós mesmos descobrir e testar o desempenho do Asterisk como um SIP Back to Back User Agent - B2BUA (em outras palavras, o Asterisk atuando como gateway). O objetivo dos testes foi responder às duas perguntas abaixo:

• Um servidor Asterisk atuando como B2BUA pode tratar quantas chamadas simultâneas?
• Qual é o custo por porta (por chamada simultânea)?

Plano de Teste

Segundo a empresa foi planejado cuidadosamente o teste de desempenho para reproduzir as condições de uma rede em produção que transporta intenso tráfego Voz sobre a rede IP. Para o teste, o Asterisk na versão 1.4.11 foi configurado como um B2BUA em um servidor que trabalha com duas CPUs dual core, 2,33 GHz. Foram executados dois conjuntos de testes. Um cenário sem transcodificação de midia e o outro com transcodificação do codec G.711 para o codec G.729. Conforme mostra este documento pdf que detalha todo o plano de testes, a metodologia usada, os arquivos de configuração e os dados de teste, o cenário mais severo é quando o Asterisk faz a tradução de voz do codec G.711 para o G.729.

Resumo dos Resultados

• Sem transcodificação: 1500 chamadas simultâneas, com um custo de US$2,00 por porta;
• Com transcodificação de G.711 para G.729: 400 chamadas simultâneas, com um custo de US$17,50 por porta.

Sem Transcodificação

O gráfico a seguir mostra a utilização de CPU e de memória do servidor que roda o Asterisk B2BUA como uma função de chamadas simultâneas. Chamadas que chegam e que saem do B2BUA usam o codec G.711 e todos os pacotes RTP atravessavam o Servidor Asterisk.

A utilização de memória foi mínima e a utilização de CPU cresceu linearmente com o número de chamadas simultâneas.

Quando chegou ao número de 1563 chamadas simultâneas, o consumo de CPU atingiu 92%. O tráfego da conexão GibitEthernet atingiu 13%, RX/TX (MB/s) 16.36/16.38, do throughput da porta (1 Gbits/s).

O preço de varejo original, no início de 2007, para este servidor era de US$3.000,00. O custo de hardware US$3.000,00 dividido por 1500 chamadas simultâneas é igual a US$2,00 por porta no Asterisk B2BUA (por porta de gateway).



Gráfico de desempenho sem transcodificação de midia

Com Transcodificação de G.711 para G.729

O seguinte gráfico mostra a utilização de CPU e de memória do servidor que executa o Asterisk B2BUA como uma função de chamadas simultâneas. O fluxo de voz das ligações que chegavam ao B2BUA usava o codec G.711 e o fluxo que saiu foi comprimido pelo Asterisk usando o codec G.729. A utilização de memória foi mínima e a utilização de CPU cresceu linearmente com o número de chamadas simultâneas.

Quanto atingiu 414 chamadas simultâneas, a utilização de CPU chegou a 93%. O tráfego da conexão Ethernet atingiu 4%, RX/TX (MB/s) 4.34/1.59, do throughput da porta.

O custo de Royalty pela licença de uso do codec G.729, disponível da Digium, custa US$10,00 por porta. O custo total do sistema é a soma de US$3.000,00 do hardware servidor e mais US$4.000,00 de custo de royalty do codec G.729 (US$10,00 por porta * 400 portas) o que totaliza um custo final de US$7.000,00.

O custo total por porta B2BUA é a divisão de US$7.000,00 por 400 chamadas simultâneas (ou seja, US$17,50 por porta de gateway).



Gráfico com transcodificação de midia



Um detalhe interessante que pode ser lido no referido pdf gerado pela empresa Transnexus, é que a compressão da mídia consome mais recurso de CPU do que o inverso, ou seja, quando o trabalho é para descompressão de voz no Asterisk, pelo menos no que diz respeito ao cenário montado. Outra informação muito interessante é a modelagem que a empresa faz. Ela fez uma extrapolação dos resultados obtidos para predizer o consumo de recursos de CPU (ou seja, o clock total do sistema) em função do número máximo de ligações simultâneas baseado em uma modelagem simples. A modelagem que autor idealizou foi expressa pela seguinte fórmula:

Recursos de CPU do Servidor = (número de CPUs ou cores) * (GHz por CPU ou core)

Usando essa linha de raciocínio e aplicando-se nesse servidor de teste, tem-se:

(4 CPU cores) * (2.33 GHz por CPU) = 9.32 GHz em recursos de CPU.

Então, tem-se:
- Sem transcodificação: 160 ligações simultâneos por 1 GHz de recurso de CPU;
- Com transcodificação de G.711 para G.729: 40 ligações simultâneos por 1 GHz de recurso de CPU.

Pode-se fazer um exercício interessante usando esses dados. É sabido que no ambiente do serviço público de telefonia residencial, a taxa de ocupação simultânea do sistema pelos assinantes residenciais é menor que 10%. Assim, esse servidor conseguiria então atender:

- 15.000 assinantes residenciais sem fazer transcodificação de mídia, e;
- 4.000 assinantes residenciais com transcodificação de G.711 para G.729.

Já em ambiente corporativo estimando uma taxa de ocupação simultânea de 20% do sistema, poder-se-ia atender:

- 7.500 usuários sem fazer transcodificação de mídia;
- 2.000 usuários com transcodificação de G.711 para G.729.

Pode-se ainda extrair desse resultado a seguinte inferência:

No mercado já existem placas de telefonia PCI Express com capacidade de 8 E1, supondo que todos os 6 slots do barramento fossem PCI-e desse servidor. Então, colocando-se 6 placa de 8 E1 se conseguiria atender 1440 ligações simultâneas com a rede telefonia pública comutada (RTPC), e nesta situação o consumo de máquina atingiria 86% da CPU, conforme o documento PDF mencionado. Usando-se placas como as Diva Server da Eico para o Asterisk que faz até o tratamento de stream de voz e entrega o pacote de voz pronto ao cartão de rede, significa que uma máquina como essa pode atender 10 mil usuários facilmente.

Diagrama Subjacente de Teste

Topologia de testes

O diagrama a seguir ilustra a rede de teste e o cenário de chamadas. O servidor que roda o Asterisk B2BUA é um servidor modelo Dell Precision 490 com duas CPUs Intel Xeon 5140 dual core, 2,33 GHz e 4 GB RAM. A distribuição Linux usada foi o CentOS 4.

Esse servidor é uma máquina classe workstation, as suas conexões de rede são GigaBit Ethernet. O subsistema de memória possui elevada taxa de transferência.

O barramento desse servidor é baseado no padrão PCI Express (2 GB/s) que tem velocidade de transferência de dados muito elevada entre dispositivos quando comparado com o PCI normal (133 MB/s). Esse barramento possui características de barramento dedicado, (é o modelo análogo de um switch LAN interligando os slots e a memória dentro da arquitetura PC) quando comparado com o barramento compartilhado do já obsoleto padrão PCI. Portanto, essa máquina tem um sistema O/I de alto desempenho.






Nesta topologia, o cliente SIPp é um programa de teste de carga que gera centenas e milhares de ligações simultâneas para serem atendidas pelo servidor SIPp cada ligação com duração de 3 minutos cursando áudio bidirecional.

Os servidores “No VoIP”, “No route”, “No Device” e “Reject” simulam as situações de falha no estabelecimento de ligações, timeout e rejeição de número quando o Asterisk tenta fechar a ligação aos seus destinos respectivos.

O servidor OSP faz a função de elemento autorizador para completar o estabelecimento da ligação, distribuidor dos possíveis destinos e a gravação de bilhetes.

Para simular então os dois cenários, idealizaram o seguinte algoritmo:
1. O cliente SIPp envia uma Requisição Invite SIP ao servidor Asterisk B2BUA.
2. O Asterisk envia um Requisição de Autorização OSP ao servidor OSP. O servidor OSP retorna um Resposta de Autorização OSP com cinco possíveis destinos em ordem aleatória.
3. O Asterisk envia um convite SIP ao destino. Somente o servidor SIPp pode atender a chamada. Os outros destinos simularam falhas de chamadas. Na média, o Asterisk tenta a chamada para dois destinos de falhas antes de conseguir completar a chamada para o servidor SIPp.
4. Quando a chamada termina, o Asterisk envia um Bilhete (CDR), para o servidor OSP.

Quando o servidor Asterisk tenta jogar uma ligação ao destino, o servidor OSP foi configurado para gerar as seguintes situações de falha:

• 20% das ligações são completadas na primeira tentativa;
• 20% das ligações falham na primeira tentativa e completam na segunda tentativa;
• 20% das ligações falham nas duas tentativas e completam na terceira tentativa;
• 20% das ligações falham nas três primeiras tentativas e completam na quarta tentativa;
• 20% das ligações falham nas primeiras quatro tentativas e completam na quinta tentativa.

Especificação da Máquina Dell Precision 490

Aqui está a especificação do servidor que roda o Asterisk citado nesse teste obtido no site da Dell americana, em 20/01/07.