> On July 17, 2014, 9:43 a.m., Paul Belanger wrote: > > Could you maybe explain why this is needed? I couldn't find anything on > > Jira / wiki that explained the need. I assume it is because of performance > > issues?
This patch is the 'sledgehammer' option for tweaking your system's performance. It was a natural extension of https://issues.asterisk.org/jira/browse/ASTERISK-23811. Say, for example, you know that don't want RTCP events. That means you don't want them from AMI, and you don't mind breaking res_hep_rtcp (now up on review board) as well. You know, beyond a shadow of a doubt, that your system will never, ever, under any circumstance, want this information. You could, of course, just filter out the events from AMI, and not load res_hep_rtcp. However, Asterisk is still doing work under the hood: (1) We are grabbing snapshots of things from the Stasis cache, and building out a new Stasis message, allocating some memory along the way (2) We're publishing the information to everyone who may want it on the Stasis message bus (3) Since there are no consumers, we're dereferencing the message, calling destructors and disposing of memory And we're doing all of this for every RTP channel, all the time. And no one wants it :-( This patch lets you get rid of all that extra work by just killing the message type. If the message type is not present, then we don't do the vast majority of what I just listed out, and things continue to move along. Will that improve performance? Sure, since you're not doing the work any more. Do we know how much? Nope, because this is so system dependent it's impossible to guess. But at least if someone *does* run into a problem, they have some options on what all their system attempts to do. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3823/#review12709 ----------------------------------------------------------- On July 17, 2014, 7:49 a.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3823/ > ----------------------------------------------------------- > > (Updated July 17, 2014, 7:49 a.m.) > > > Review request for Asterisk Developers and Corey Farrell. > > > Repository: Asterisk > > > Description > ------- > > This introduces stasis.conf and a mechanism to prevent certain message types > from being published. > > > Diffs > ----- > > trunk/tests/test_stasis_channels.c 418715 > trunk/tests/test_stasis.c 418715 > trunk/main/stasis_message.c 418715 > trunk/main/stasis_cache.c 418715 > trunk/main/stasis.c 418715 > trunk/include/asterisk/stasis.h 418715 > trunk/configs/stasis.conf.sample PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/3823/diff/ > > > Testing > ------- > > Tested by causing the stasis unittests to fail with the following stasis.conf > configuration: > [declined_message_types] > decline=TestMessage > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- 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
