[asterisk-dev] [Code Review] 2883: Performance: Optimize how Stasis forwards are dispatched
Mark Michelson
reviewboard at asterisk.org
Fri Sep 27 16:05:36 CDT 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2883/#review9846
-----------------------------------------------------------
Ship it!
/team/dlee/taskprocessor-optimization/include/asterisk/vector.h
<https://reviewboard.asterisk.org/r/2883/#comment19042>
The doxygen for the comparator is confusing. Since "value" is the argument given to the macro, it sounds like this would be the second parameter passed to the comparator. However, this is actually the first parameter passed to the comparator.
- Mark Michelson
On Sept. 27, 2013, 7:04 p.m., David Lee wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2883/
> -----------------------------------------------------------
>
> (Updated Sept. 27, 2013, 7:04 p.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Repository: Asterisk
>
>
> Description
> -------
>
> This patch optimizes how forwards are dispatched in Stasis.
>
> Originally, forwards were dispatched as subscriptions that are invoked
> on the publishing thread. This did not account for the vast number of
> forwards we would end up having in the system, and the amount of work it
> would take to walk though the forward subscriptions.
>
> This patch modifies Stasis so that rather than walking the tree of
> forwards on every dispatch, when forwards and subscriptions are changed,
> the subscriber list for every topic in the tree is changed.
>
> This has a couple of benefits. First, this reduces the workload of
> dispatching messages. It also reduces contention when dispatching to
> different topics that happen to forward to the same aggregation topic
> (as happens with all of the channel, bridge and endpoint topics).
>
> Since forwards are no longer subscriptions, the bulk of this patch is
> simply changing stasis_subscription objects to stasis_forward objects
> (which, admittedly, I should have done in the first place.)
>
> Since this required me to yet again put in a growing array, I finally
> abstracted that out into a set of ast_vector macros in
> asterisk/vector.h.
>
>
> Diffs
> -----
>
> /team/dlee/taskprocessor-optimization/apps/app_queue.c 399869
> /team/dlee/taskprocessor-optimization/include/asterisk/stasis.h 399869
> /team/dlee/taskprocessor-optimization/include/asterisk/vector.h PRE-CREATION
> /team/dlee/taskprocessor-optimization/main/cdr.c 399869
> /team/dlee/taskprocessor-optimization/main/cel.c 399869
> /team/dlee/taskprocessor-optimization/main/channel_internal_api.c 399869
> /team/dlee/taskprocessor-optimization/main/manager.c 399869
> /team/dlee/taskprocessor-optimization/main/manager_bridges.c 399869
> /team/dlee/taskprocessor-optimization/main/manager_channels.c 399869
> /team/dlee/taskprocessor-optimization/main/manager_mwi.c 399869
> /team/dlee/taskprocessor-optimization/main/manager_system.c 399869
> /team/dlee/taskprocessor-optimization/main/stasis.c 399869
> /team/dlee/taskprocessor-optimization/main/stasis_cache_pattern.c 399869
> /team/dlee/taskprocessor-optimization/res/stasis/app.c 399869
> /team/dlee/taskprocessor-optimization/tests/test_stasis.c 399869
> /team/dlee/taskprocessor-optimization/tests/test_stasis_endpoints.c 399869
>
> Diff: https://reviewboard.asterisk.org/r/2883/diff/
>
>
> Testing
> -------
>
> Unit tests pass.
>
> Performance testing to verify the speed up.
>
>
> Thanks,
>
> David Lee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130927/3072f62e/attachment-0001.html>
More information about the asterisk-dev
mailing list