Descubra quantas chamadas simultâneas o Asterisk suporta?

Fizemos o teste nas VMs da Amazon para saber quantas chamadas simultâneas o Asterisk suporta, com segurança, sem perder a qualidade da voz e funcionamento dos demais serviços rodando no sistema operacional.

É claro que, para chegar em um número, precisamos “congelar” algumas das N variáveis existentes, tais como: Sistema operacional, tamanho de memória, tipo de processador, versão do asterisk, compilador, codec, hardware físico vs VM, entre outros. A mudança de alguma destas variáveis pode acarretar em números diferentes dos obtidos aqui, para mais ou para menos.

Portanto, o intuito deste post é passar um valor de referência – apenas.

Vou dividir este post em algumas etapas:

• A) Resultado Obtido
• B) Topologia
• C) Configurações e Hardware utilizado nos testes
• D) Teste Realizado
• E) Conclusão

A) Resultado Obtido

Chegamos aos valores abaixo, já considerando uma margem de segurança para um bom funcionamento do sistema operacional, sem comprometimento dos demais serviços básicos:

Asterisk sem controle de áudio (RTP):

Obtivemos uma marca de 3.000 active channels = 1500 chamadas simultâneas.

Com controle de RTP:

Obtivemos uma marca de 600 active channels = 300 chamadas simultâneas.

B) Topologia

Topologia utilizado nos testes:

C) Configurações e Hardware utilizado nos testes

Os ramais 10 e 20, são telefones da marca Yealink.

Os servidores Asterisk A e Asterisk B, interligados via tronco SIP, são VM (virtual machine) hospedados na Amazon. As configurações destas VMs foram:

• Debian Server 9 64 bits
• 2 VCPUs 2.4Ghz
• 4GB memória RAM
• 8GB disco magnético
• Asterisk 13.24.1
• MySQL 5.6

Abaixo segue uma imagem referente ao processador utilizado nos servidores:

Nos servidores A e B, deixamos instalado o MySQL. Com intuito de gerar algum processamento extra, configuramos o asterisk para salvar no banco os dados referente ao CDR. Também configuramos para salvar os dados referente ao CEL no MySQL. Neste último caso, configuramos via ODBC.

Não desativamos nenhum módulo do asterisk, deixando o “pacote padrão” instalado, adicionando alguns módulos referente a conexão do MySQL.

Para o entroncamento SIP entre os servidores, utilizamos liberação via IP, sem registro. SIP trunk configurado com codec g711a (alaw).

O ramal 10 conseguia discar para o ramal 20, e vice-versa. Utilizamos estes ramais unicamente para mantermos a conversação entre 2 pessoas, medindo qualquer possível interferência na qualidade.

D) Teste Realizado

Foram 2 testes realizados para sentir o comportamento do Asterisk. O primeiro teste, sem RTP, é o teste no qual o Asterisk gerencia somente as conexões SIP, e a voz (RTP), passa diretamente entre a origem e o destino.
Já o segundo teste, forçamos para que o Asterisk gerenciasse a voz, passando todo o tráfego de RTP por ele. O que resulta em 50 pacotes por segundo, por canal, para ele processar.

Em ambos os servidores colocamos um script discador, criado em PHP, responsável por originar chamadas de um servidor para o outro, em uma velocidade de 20 chamadas por segundo. O outro servidor – que recebia a chamada – atendia a chamada e segurava atendida por 10 mil segundos (167 minutos), com o comando WaitExten(10000), para os testes sem RTP.
Já para os testes com RTP, montamos um loop, em ambos os servidores, tocando sempre o áudio tt-weasels, utilizando o áudio em GSM.

Desta forma conseguimos medir a capacidade dos servidores com e sem a gerência do áudio RTP transitando por eles.

Enquanto o discador era executado, ficávamos conversando entre os ramais 10 e 20, buscando identificar qualquer comprometimento com a qualidade, bem como testando o tempo de completamento da chamada.

Teste sem RTP:

O valor máximo de chamadas simultânea constatado ao rodar o comando “core show channels verbose”, foi de 3938 active channels conforme print abaixo:

Teste com RTP:

Já quando colocamos áudio em cima dos servidores, utilizando o RTP, o valor máximo ficou em 728 active channels:

Neste último caso do teste realizado com RTP, temos que considerar ainda que estávamos executando um arquivo de áudio (tt-weasels) sendo aberto para cada chamada, em um loop infinito. Propositalmente criado para gerar um processamento extra na máquina, com intuito de nos aproximarmos de um processamento real. Além disso, em ambos os testes, temos o CEL e o CDR sendo escritos no MySQL.

Em ambos os casos acima, o load da VM estava superior a 2.0, sendo possível notar picotes na voz e uma leve lentidão ao sistema via SSH.

Refizemos os testes em busca de um resultado seguro, onde não houvesse picote de voz, nem mesmo lentidão, com load inferior a 2.0. E chegamos aos valores apresentados no item A (Resultados Obtidos) deste post: 3000 active channels sem RTP e 600 active channels com RTP.

E) Conclusão

Neste teste conseguimos atingir o objetivo de obter um valor de referência de quantas chamadas o asterisk suporta, dado as condições entregues para os testes.

De certo ponto de vista, é incorreto falarmos de “quantas chamadas o asterisk suporta“, visto que o limitador muitas vezes é o hardware e não o software. De qualquer forma, julgo ser um número importante para fins de referência, para termos ideia de cálculo de hardware necessário para atender cada caso. Adicionalmente, tal número também pode ser interessante para fins de comparação de diferentes software de PABX rodando no mesmo hardware.

Também é válido chamar a atenção de que 300 chamadas simultâneas, em um servidor dual core, certamente é um número bastante atrativo, que atende um número superior a 99% das empresas brasileiras.

Com certeza este número poderá ainda ser superior com algumas mudanças, principalmente relacionadas a utilização de um hardware físico ao invés de VM, com maior capacidade de processamento, desativação de módulos desnecessários do asterisk, e demais ajustes finos a nível de sistema operacional.