[asterisk-dev] [Code Review] 2883: Performance: Optimize how Stasis forwards are dispatched

[rmudgett]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2883/#review9852
-----------------------------------------------------------



/team/dlee/taskprocessor-optimization/include/asterisk/vector.h
<https://reviewboard.asterisk.org/r/2883/#comment19046>

    Why not return the elem removed from the vector like ast_vector_remove_unordered().


- rmudgett


On Sept. 27, 2013, 10:03 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, 10:03 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/3be6c0a6/attachment-0001.html>