[asterisk-dev] How to get to 10.000 open calls

[Sergey Okhapkin]

My dream is chan_openser.so...

On Wednesday 22 April 2009 03:36:59 am Alex Balashov wrote:
> A proxy derived from the OpenSER stack could do it.
>
> Venefax wrote:
> > Yes, I have the box. And I will get the calls next week. I was thinking
> > to use the Asterisk feature where you can start different Asterisk using
> > -C \path_to\config\file, and start 15 instances. But to be able to load
> > balance it is a nightmare, since many clients do not accept or follow
> > redirects (SIP 302 Moved). I am out of tricks, unless I setup another
> > technology for load balancing but then why not use the same (x)
> > technology for everything? What technology would that be that can handle
> > 10.000 sip connections, not touching the media? My Cisco 7301 would not
> > scale so far out.
> >
> > -----Original Message-----
> > From: asterisk-dev-bounces at lists.digium.com
> > [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tzafrir Cohen
> > Sent: Wednesday, April 22, 2009 3:19 AM
> > To: asterisk-dev at lists.digium.com
> > Subject: Re: [asterisk-dev] How to get to 10.000 open calls
> >
> > On Wed, Apr 22, 2009 at 02:48:11AM -0400, Venefax wrote:
> >> I am using 1.6.2 and directrtp=yes. I need to scale to 10.000 open calls
> >
> > on
> >
> >> a box with 1288 GB or RAM and 16 Cores. Is there any modification to the
> >> source code that would be obvious, any bottlenecks? I will never to
> >> transcoding and the media should, theoretically, flow outside. I have 15
> >
> > IP
> >
> >> addresses already configured in the same box, on two different nics, to
> >> spread the interrupts. Is this a dream or will this work with some
> >
> > tweaking?
> >
> > Do you have the system now?
> >
> > While it's most likely be a dream, identifying the current bottlenecks
> > might  be useful :-)
> >
> > Just a few uneducated guesses of my own:
> >
> > * More than one IP per NIC won't help and only cause some administrative
> >   issues
> > * I'm not sure how much the extra memory can help. I suspect htat if you
> >   boot the system with mem=<whatever_needed_for_16GB> the results won't
> >   differ greatly
> > * It would also be interesting to see how the results scale with various
> >   values numbers of cores. This is again something you can set at boot
> >   (numcpus=N). I wonder just how far from linear it will be.