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
