diff options
author | Matthew Jordan <mjordan@digium.com> | 2014-12-01 17:59:21 +0000 |
---|---|---|
committer | Matthew Jordan <mjordan@digium.com> | 2014-12-01 17:59:21 +0000 |
commit | 1106e8fd0f831c79eb2a7cf079739561da11d6ef (patch) | |
tree | 3e841771528c621760a6b0471935bc432e704054 /CHANGES | |
parent | ef9ca8bc32c7cce781c35bca81d9ae544fd22dae (diff) |
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
Diffstat (limited to 'CHANGES')
-rw-r--r-- | CHANGES | 12 |
1 files changed, 11 insertions, 1 deletions
@@ -39,6 +39,16 @@ chan_pjsip the message will automatically be associated with the configured endpoint on the outbound registration. + +Core +------------------ + * The core of Asterisk uses a message bus called "Stasis" to distribute + information to internal components. For performance reasons, the message + distribution was modified to make use of a thread pool instead of a + dedicated thread per consumer in certain cases. The initial settings for + the thread pool can now be configured in 'stasis.conf'. + + Functions ------------------ @@ -355,7 +365,7 @@ AMI * AMI action PJSIPNotify may now send to a URI instead of only to a PJSIP endpoint as long as a default outbound endpoint is set. This also applies to the equivalent CLI command (pjsip send notify) - + * The AMI action PJSIPShowEndpoint now includes ContactStatusDetail sections that give information on Asterisk's attempts to qualify the endpoint. |