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

[svnbot]

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

(Updated Sept. 30, 2013, 1:39 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 400180


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/20130930/7a198e1e/attachment.html>