[SR-Users] Dimension a kamailio server

[Pedro Niño]

As Alex said, I/O and calls per second (CPS) is Dependant on what type of
design you are using.

As a tip, mysql is good for small to medium sizes, but begin to choke at
1000 of concurrent connections. but in a scalable size like you are
planning, I would recommend to make a design with resilience and high
availability, with mongodb or postgres as db back end.

There are some good examples on internet about enabling multiple kamailio
server with high availability configuration, using heartbeat and some other
scripts.

A nice design would be:

2 or more kamailio servers, maybe virtual or physical, with high
availability configuration (if one goes down, the other takes all the load)

2 or more DB servers, also with high availability design.

At least 10G connection, server and switch (for the call flow you're
expecting) remember to make estimation for calls established, and codec
used, (using g711, rtp audio might come up to 80kbps, so like 120.000 calls
is the top for a 10G connection)

Also separate vlan for calls and server control, too.

Just my 2 cents
El mar 28, 2014 11:58 AM, "Rizwan Khan" <rizkhan at gmail.com> escribió:

> Thanks Alex.
>
> What are the components that I should take into account. Based on answer
> in another thread I will be using  SIP trunk with an NGN to route the
> outside traffic (other than SIP-SIP).
>
> I'll have NATed clients so I'll need the media proxy or rtp proxy as well.
> What about their dimensioning? I am sorry if some questions are really
> naive. I am new to all this and trying to get hold of the whole technology
> stack.
>
> Rizwan
> On Mar 28, 2014 3:41 PM, "Alex Balashov" <abalashov at evaristesys.com>
> wrote:
>
>> 1. Kamailio does not handle RTP, so audio is not a scaling factor at all;
>>
>> 2. The only scaling factors are transactional memory (TM) and any dialog
>> state you are keeping;
>>
>> 3. Without I/O wait from external sources, Kamailio can handle a
>> practically infinite amount of concurrent calls and CPS. But, most
>> practical applications of Kamailio require database backing;
>>
>> 4. Therefore, performance and throughput will depend almost entirely on
>> the database you are using for database backing, and any tuning on its
>> settings. This certainly includes the CDRs and storage, and getting the
>> most performance out of your database is outside the domain of your
>> question (or this list);
>>
>> 5. A quad-core host with 8 GB of RAM should be more than sufficient for
>> Kamailio itself to meet your needs. But most of the answers to your
>> question don't have much to do with Kamailio.
>>
>> -- Alex
>>
>> On 03/28/2014 06:36 AM, Rizwan Khan wrote:
>>
>>  HI Guys,
>>>
>>> can you refer me to some resources which help me dimension the hardware
>>> for a setup.
>>>
>>> Total users will be 20,000. What percentage should i assume for
>>> concurrent audio and video calls? What is the standard practice? How
>>> does this all map to the cpu, ram and storage etc. given that I will be
>>> storing the cdrs as well.
>>>
>>> In the futute this setup should be scalable so that it should support
>>> 200,000+ users within a span of 6-8 months. What would be the ideal
>>> architecture?
>>>
>>> Thanks,
>>>
>>> Rizwan Khan
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> --
>> Alex Balashov - Principal
>> Evariste Systems LLC
>> 235 E Ponce de Leon Ave
>> Suite 106
>> Decatur, GA 30030
>> United States
>> Tel: +1-678-954-0670
>> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140330/e40b9387/attachment.html>