[Asterisk-Users] re: call "load balancing"

[Tzafrir Cohen]

On Sat, Aug 13, 2005 at 12:41:15AM -0700, Luki wrote:
> > However: this means that a bug that makes Asterisk consume
> > 100%CPU will practically stall the system. The system will
> > still answer pings and open sockets, because that is done
> > in the kernel. But nothing further will be done.
> 
> Correct. Same if, for any reason, you have a loop in your dial-plan.
> Box is dead but responds to pings, etc. Not exactly a great solution
> killing everything on a server because of one buggy process. That is
> why I don't use -p.

http://lists.digium.com/pipermail/asterisk-dev/2005-May/012434.html
http://lists.digium.com/pipermail/asterisk-dev/2005-May/012439.html

> 
> Can anyone comment on the performance differences with the 2.4 vs. 2.6
> kernel on a semi-loaded (meaning not idle) box? I seem to get better
> responsiveness on a 2.6 kernel.

You should expect that. Look for more information about preemption. This
is one of the major changes between 2.4 and 2.6.

> 
> htb on Linux works fine for me on the same box for outgoing traffic
> shaping. Can be the same machine that is running Asterisk as long as
> it's also acting as a gateway and nothing else competes for the link.
> Seems to improve flow quite a bit on a congested link.

Asterisk wants fast access to the CPU. iptables and iproute's tc as well(?)
allow you to define a more complex path in which each packet travels.
This means:

1. more CPU time of the asterisk box invested in each packet. That task
   has a higher priority that Asterisk (even with -p)

2. delays on packets. This only really matters for packets of audio
   data.

If you know what you're doing, then you actually don't delay (when
unless really necessary) sound packets, so it should be fine. 

As for (1): I don't know tc. I've seen some ill-composed iptables rules
that moves all packets through a complex set of rules. Usually one
indication to that would be that the CPU spends non-negligable time in
"system". But if you have a zaptel card, this is something you should
expect anyway.

-- 
Tzafrir Cohen         | tzafrir at jbr.cohens.org.il | VIM is
http://tzafrir.org.il |                           | a Mutt's  
tzafrir at cohens.org.il |                           |  best
ICQ# 16849755         |                           | friend