On Sun, Jul 6, 2008 at 9:08 AM, Stephen Davies <[EMAIL PROTECTED]> wrote: > > > 2008/7/6 Grey Man <[EMAIL PROTECTED]>: >> >> From what I can gather the suggestion from the FS approach is that >> each Asterisk channel should be handled after by it's own unique >> thread and save the need for any locking on the channel data >> structures in the first place. > > > After a quick grep, there are lots of mutex locks and unlocks in the FS > code. As you would expect. > I guess Steve Totaro's "grunt techs" know that, whilst Steve has drunk the > koolaid (and is trolling, anyway).
Wrong again. > > Nevertheless - the suggestion as I understand it is that there is less > contention for locks in FS due to the design choice that one thread is > created that handles one active channel. I guess the theory is that > _everything_ done on that channel is done in that thread. By contrast, we > have a mix of design styles like the worker threads, network threads etc. > > But we don't have evidence that contention for mutexes (aka locks) is > slowing Asterisk down. So it there is a big performance different it will > probably be elsewhere - like the linked lists that are already getting > attention. Lack of evidence means absolutely nothing, besides you are clueless. > > My curiosity is piqued to do a proper comparison of Asterisk and Freeswitch > with a realistic workload and compare results (and profile Asterisk if there > is a big difference. > > Steve So again, I pose the question, why a 10X improvement? I will compare the two on the same hardware, but for what its worth, (the name that cannot spoke) shows how much slower Asterisk is. Thanks, Steve Totarao _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
