Hello,
I now compared SIP against IAX performance on Russel's branch.
I flooded the server with registrations (900) with 1 ms in between.
During this process I try to launch a call, with SIP or IAX based on the
flooding I am doing. Asterisk answers the call and plays a sound file.
With SIP things are great. The call is connected really fast. With IAX
it is a whole other story. It takes a hell lof of time to get connected.
The IAX protocol is just not responsive
The number of channels sip show channels or iax show channels is
similar. Just to make sure both flood tools do approximately the same.
Now, I guess on IAX it is related how many threads I configure inside
iax.conf
For now my settings are:
iaxthreadcount = 100
iaxmaxthreadcount = 150
I think the highes value possible is 512 which I tried but it did not
really improve the situation.
The setting of rtcachefriends in the config has no impact my my test
results.
Can anyone confirm those results? Compared to SIP it is at the moment
too easy to DOS IAX because of the poor performance. No fast internet
connection needed. Just a few UDP packages and IAX is down.
I do not say that this is different on some older iax implementations.
So I think the latest developments are some big improvements and should
be merged quite soon, depending on more test results.
Best regards,
Loic Didelot.
On Fri, 2007-08-17 at 16:20 -0400, Russell Bryant wrote:
Greetings,
I have a branch where I have fixed some bugs in chan_iax2. The code is
intended
to go in both 1.4 and trunk. The changes are rather invasive, so I wanted to
describe the changes and justify them before merging them in.
svn diff http://svn.digium.com/svn/asterisk/branches/1.4/channels/chan_iax2.c
http://svn.digium.com/svn/asterisk/team/russell/iax_refcount/channels/chan_iax2.c
This branch is targeted at fixing a set of crashes. They were brought to my
immediate attention by being given access to a system that could be easily
crashed by issuing a reload while running a registration load test.
The problems turned out to be related to the handling of iax2_peer objects.
However, the handling of iax2_user objects suffers from the same problems so
the
same changes have been made to them, as well. There are various situations
where peers could get destroyed while other threads still hold references to
them.
To fix this problem, I made it so the objects are reference counted. To do
this, I had 3 choices.
1) Don't use any object model. Just write it in manually. This felt like
the
worst choice. It's best to use a common implementation when possible.
2) Use astobj.h. This hasn't made it very far throughout the code base. The
API is a set of macros which are cumbersome to use, and especially to debug,
in
my opinion. However, it's certainly better than option #1, as it is a common
implementation already in use in some places. However, it is likely that this
is going to be deprecated in favor of astobj2.
3) Use astobj2. Luigi Rizzo and one of his students, Marta Carbone, have
written a new reference counted object model and have had it in a branch for a
long time now. After reviewing astobj versus astobj2, I perferred astobj2,
and
decided to go with that. It doesn't use macros, and is still more efficient.
Another reason that I chose to go with astobj2 was that I *know* this is not
the
end of problems of this type. In fact, there is a nice set of crashes on the
bug tracker which the fix will be converting the ast_channel struct over to a
reference counted object model, which is going to be a big job. Since we are
likely going to have to do more conversions of object handling to this
method, I
figured it was worth bringing in astobj2 to 1.4 so that we can use it as
needed,
and not do all of this work using a model that we know will be deprecated in
the
near future.
If you have any comments or objections, I would like to hear them. Also, feel
free to ask for any clarification or more detailed explanations of the things
I
have mentioned here.
If there are no objections, I will be merging these changes into 1.4 next
week.
--
Loic DIDELOT (CTO)
voipGATE S.A.
Tel: +352 20 200 223
Fax: +352 20 200 923
E-mail: [EMAIL PROTECTED]
Web: http://www.voipgate.com
___
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
