<br><br><div class="gmail_quote">On Tue, Aug 25, 2009 at 8:59 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net">oej@edvina.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Asterisk users around the world!<br>
<br>
Recently, I have been working with pretty large Asterisk<br>
installations. 300 servers running Asterisk and Kamailio (OpenSER).<br>
Replacing large Nortel systems with just a few tiny boxes and other<br>
interesting solutions. Testing has been a large part of these<br>
projects. How much can we put into one Asterisk box? Calls per euro<br>
invested matters.<br>
<br>
So far, we've been able to reach about 2000 channels of G.711 with<br>
quad core CPU's and Intel Pro/1000 network cards in IBM servers. At<br>
that point, we see that IRQ balancer gives up and goes to bed, and all<br>
the traffic is directed to one core and the system gives up. We've<br>
been running these tests on several systems, with different NICs and<br>
have been working hard to tweak capacity. New drivers, new cards, new<br>
stuff. But all indications told us that the problem was the CPU<br>
context switching between handling network traffic (RTP traffic) and<br>
Asterisk. This was also confirmed from a few different independent<br>
software development teams.<br>
<br>
Imaging my surprise this Monday when I installed a plain old Asterisk<br>
1.4 on a new HP server, a DL380 G6, and could run in circles around<br>
the old IBM servers. Three servers looping calls between them and we<br>
bypassed 10.000 channels without any issues. SIP to SIP calls, the<br>
p2p RTP bridge, basically running a media proxy. At that point, our<br>
cheap gigabit switch gave up, and of course the NICs. Pushing 850 Mbit<br>
was more than enough. The CPU's (we had 16 of them with<br>
hyperthreading) was not very stressed. Asterisk was occupying a few of<br>
them in a nice way, but we had a majority of them idling around<br>
looking for something to do.<br>
<br>
So, please help me. I need answers to John Todds questions while he's<br>
treating me with really good expensive wine at Astricon. How did this<br>
happen? Was it the Broadcom NICs? Was it the Intel 5530 Xeon CPU's? Or<br>
a combination? Or maybe just the cheap Netgear switch...<br>
<br>
I hope to get more access to these boxes, three of them, to run tests<br>
with the latest code. In that version we have the new hashtables, all<br>
the refcounters and fancy stuff that the Digium team has reworked on<br>
the inside of Asterisk. The trunk version will propably behave much,<br>
much better than 1.4 when it comes to heavy loads and high call setup<br>
rates.<br>
<br>
We're on our way to build a new generation of Asterisk, far away from<br>
the 1.0 platform. At the same time, the hardware guys have obviously<br>
not been asleep. They're giving us inexpensive hardware that makes our<br>
software shine. Now we need to test other things and see how the rest<br>
of Asterisk scales, apart from the actual calls. Manager, events,<br>
musiconhold, agi/fastagi... New interesting challenges.<br>
<br>
So take one of these standard rack servers from HP and run a telco for<br>
a small city on one box. While you're at it, buy a spare one, hardware<br>
can fail ( ;-) ).<br>
But don't say that Asterisk does not scale well. Those times are gone.<br>
<br>
/Olle<br>
<br>
---<br>
* Olle E Johansson - <a href="mailto:oej@edvina.net">oej@edvina.net</a><br>
* Open Unified Communication - SIP & XMPP projects<br>
<br>
</blockquote><div><br>I always was a fan and recommended IBM DL380s if not 360s (dual power supply).<br><br>I would like to see some benchmarking on the AMI. Not sure how to do it but that used to be a very weak link. I wonder if, and how much it has improved over 1.2.x <br>
</div></div><br>-- <br>Thanks,<br>Steve Totaro <br>+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>