2013-03-15 17:35:16 +00:00
|
|
|
/*
|
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2013, Digium, Inc.
|
|
|
|
|
*
|
|
|
|
|
* David M. Lee, II <dlee@digium.com>
|
|
|
|
|
*
|
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
|
* channels for your use.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
|
* at the top of the source tree.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _ASTERISK_STASIS_MESSAGE_ROUTER_H
|
|
|
|
|
#define _ASTERISK_STASIS_MESSAGE_ROUTER_H
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief A simplistic router for \ref stasis_message's.
|
|
|
|
|
*
|
|
|
|
|
* Often times, when subscribing to a topic, one wants to handle different
|
|
|
|
|
* message types differently. While one could cascade if/else statements through
|
|
|
|
|
* the subscription handler, it is much cleaner to specify a different callback
|
|
|
|
|
* for each message type. The \ref stasis_message_router is here to help!
|
|
|
|
|
*
|
|
|
|
|
* A \ref stasis_message_router is constructed for a particular \ref
|
|
|
|
|
* stasis_topic, which is subscribes to. Call
|
|
|
|
|
* stasis_message_router_unsubscribe() to cancel that subscription.
|
|
|
|
|
*
|
|
|
|
|
* Once constructed, routes can be added using stasis_message_router_add() (or
|
|
|
|
|
* stasis_message_router_set_default() for any messages not handled by other
|
|
|
|
|
* routes). There may be only one route per \ref stasis_message_type. The
|
|
|
|
|
* route's \a callback is invoked just as if it were a callback for a
|
|
|
|
|
* subscription; but it only gets called for messages of the specified type.
|
|
|
|
|
*
|
|
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "asterisk/stasis.h"
|
|
|
|
|
|
|
|
|
|
/*! \brief Stasis message routing object */
|
|
|
|
|
struct stasis_message_router;
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Create a new message router object.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \param topic Topic to subscribe route to.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \return New \ref stasis_message_router.
|
|
|
|
|
* \return \c NULL on error.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
struct stasis_message_router *stasis_message_router_create(
|
|
|
|
|
struct stasis_topic *topic);
|
|
|
|
|
|
main/stasis: Allow subscriptions to use a threadpool for message delivery
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01 17:59:21 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Create a new message router object.
|
|
|
|
|
*
|
|
|
|
|
* The subscription created for this message router will dispatch
|
|
|
|
|
* callbacks on a thread pool.
|
|
|
|
|
*
|
|
|
|
|
* \param topic Topic to subscribe route to.
|
|
|
|
|
*
|
|
|
|
|
* \return New \ref stasis_message_router.
|
|
|
|
|
* \return \c NULL on error.
|
|
|
|
|
*
|
|
|
|
|
* \since 12.8.0
|
|
|
|
|
*/
|
|
|
|
|
struct stasis_message_router *stasis_message_router_create_pool(
|
|
|
|
|
struct stasis_topic *topic);
|
|
|
|
|
|
2013-03-15 17:35:16 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Unsubscribe the router from the upstream topic.
|
2013-05-17 21:10:32 +00:00
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \param router Router to unsubscribe.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
void stasis_message_router_unsubscribe(struct stasis_message_router *router);
|
|
|
|
|
|
2013-05-17 21:10:32 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Unsubscribe the router from the upstream topic, blocking until the
|
|
|
|
|
* final message has been processed.
|
|
|
|
|
*
|
|
|
|
|
* See stasis_unsubscribe_and_join() for info on when to use this
|
|
|
|
|
* vs. stasis_message_router_unsubscribe().
|
|
|
|
|
*
|
|
|
|
|
* \param router Router to unsubscribe.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-05-17 21:10:32 +00:00
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
void stasis_message_router_unsubscribe_and_join(
|
|
|
|
|
struct stasis_message_router *router);
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Returns whether \a router has received its final message.
|
|
|
|
|
*
|
|
|
|
|
* \param router Router.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-05-17 21:10:32 +00:00
|
|
|
* \return True (non-zero) if stasis_subscription_final_message() has been
|
|
|
|
|
* received.
|
|
|
|
|
* \return False (zero) if waiting for the end.
|
|
|
|
|
*/
|
|
|
|
|
int stasis_message_router_is_done(struct stasis_message_router *router);
|
|
|
|
|
|
2014-01-12 22:07:01 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Publish a message to a message router's subscription synchronously
|
|
|
|
|
*
|
|
|
|
|
* \param router Router
|
|
|
|
|
* \param message The \ref stasis message
|
|
|
|
|
*
|
|
|
|
|
* This should be used when a message needs to be published synchronously to
|
|
|
|
|
* the underlying subscription created by a message router. This is analagous
|
|
|
|
|
* to \ref stasis_publish_sync.
|
|
|
|
|
*
|
|
|
|
|
* Note that the caller will be blocked until the thread servicing the message
|
|
|
|
|
* on the message router's subscription completes handling of the message.
|
|
|
|
|
*
|
|
|
|
|
* \since 12.1.0
|
|
|
|
|
*/
|
|
|
|
|
void stasis_message_router_publish_sync(struct stasis_message_router *router,
|
|
|
|
|
struct stasis_message *message);
|
|
|
|
|
|
2013-03-15 17:35:16 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Add a route to a message router.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-07-23 13:39:50 +00:00
|
|
|
* A particular \a message_type may have at most one route per \a router. If
|
|
|
|
|
* you route \ref stasis_cache_update messages, the callback will only receive
|
|
|
|
|
* updates for types not handled by routes added with
|
|
|
|
|
* stasis_message_router_add_cache_update().
|
|
|
|
|
*
|
Multiple revisions 399887,400138,400178,400180-400181
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
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.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
|
|
|
* Adding multiple routes for the same message type results in undefined
|
|
|
|
|
* behavior.
|
|
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \param router Router to add the route to.
|
|
|
|
|
* \param message_type Type of message to route.
|
|
|
|
|
* \param callback Callback to forard messages of \a message_type to.
|
|
|
|
|
* \param data Data pointer to pass to \a callback.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
|
|
|
|
* \retval 0 on success
|
|
|
|
|
* \retval -1 on failure
|
|
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
int stasis_message_router_add(struct stasis_message_router *router,
|
2013-07-23 13:39:50 +00:00
|
|
|
struct stasis_message_type *message_type,
|
|
|
|
|
stasis_subscription_cb callback, void *data);
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Add a route for \ref stasis_cache_update messages to a message router.
|
|
|
|
|
*
|
|
|
|
|
* A particular \a message_type may have at most one cache route per \a router.
|
|
|
|
|
* These are distinct from regular routes, so one could have both a regular
|
|
|
|
|
* route and a cache route for the same \a message_type.
|
|
|
|
|
*
|
Multiple revisions 399887,400138,400178,400180-400181
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
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.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
|
|
|
* Adding multiple routes for the same message type results in undefined
|
|
|
|
|
* behavior.
|
|
|
|
|
*
|
2013-07-23 13:39:50 +00:00
|
|
|
* \param router Router to add the route to.
|
|
|
|
|
* \param message_type Subtype of cache update to route.
|
|
|
|
|
* \param callback Callback to forard messages of \a message_type to.
|
|
|
|
|
* \param data Data pointer to pass to \a callback.
|
|
|
|
|
*
|
|
|
|
|
* \retval 0 on success
|
|
|
|
|
* \retval -1 on failure
|
|
|
|
|
*
|
|
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
int stasis_message_router_add_cache_update(struct stasis_message_router *router,
|
|
|
|
|
struct stasis_message_type *message_type,
|
|
|
|
|
stasis_subscription_cb callback, void *data);
|
2013-03-15 17:35:16 +00:00
|
|
|
|
2013-06-06 19:44:45 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Remove a route from a message router.
|
|
|
|
|
*
|
Multiple revisions 399887,400138,400178,400180-400181
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
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.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
|
|
|
* If a route is removed from another thread, there is no notification that
|
|
|
|
|
* all messages using this route have been processed. This typically means that
|
|
|
|
|
* the associated \c data pointer for this route must be kept until the
|
|
|
|
|
* route itself is disposed of.
|
|
|
|
|
*
|
2013-06-06 19:44:45 +00:00
|
|
|
* \param router Router to remove the route from.
|
|
|
|
|
* \param message_type Type of message to route.
|
|
|
|
|
*
|
|
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
void stasis_message_router_remove(struct stasis_message_router *router,
|
2013-07-23 13:39:50 +00:00
|
|
|
struct stasis_message_type *message_type);
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
* \brief Remove a cache route from a message router.
|
|
|
|
|
*
|
Multiple revisions 399887,400138,400178,400180-400181
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
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.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
|
|
|
* If a route is removed from another thread, there is no notification that
|
|
|
|
|
* all messages using this route have been processed. This typically means that
|
|
|
|
|
* the associated \c data pointer for this route must be kept until the
|
|
|
|
|
* route itself is disposed of.
|
|
|
|
|
*
|
2013-07-23 13:39:50 +00:00
|
|
|
* \param router Router to remove the route from.
|
|
|
|
|
* \param message_type Type of message to route.
|
|
|
|
|
*
|
|
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
void stasis_message_router_remove_cache_update(
|
|
|
|
|
struct stasis_message_router *router,
|
|
|
|
|
struct stasis_message_type *message_type);
|
2013-06-06 19:44:45 +00:00
|
|
|
|
2013-03-15 17:35:16 +00:00
|
|
|
/*!
|
|
|
|
|
* \brief Sets the default route of a router.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \param router Router to set the default route of.
|
|
|
|
|
* \param callback Callback to forard messages which otherwise have no home.
|
|
|
|
|
* \param data Data pointer to pass to \a callback.
|
2013-06-06 19:44:45 +00:00
|
|
|
*
|
|
|
|
|
* \retval 0 on success
|
|
|
|
|
* \retval -1 on failure
|
|
|
|
|
*
|
2013-03-15 17:35:16 +00:00
|
|
|
* \since 12
|
|
|
|
|
*/
|
|
|
|
|
int stasis_message_router_set_default(struct stasis_message_router *router,
|
|
|
|
|
stasis_subscription_cb callback,
|
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
|
|
#endif /* _ASTERISK_STASIS_MESSAGE_ROUTER_H */
|