During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
........
Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This essentially makes app_queue usable again. From reviewboard:
* Reporting of transfers and call completion is done by creating stasis
subscriptions and listening for specific events in order to determine
when the call is finished (either via a transfer or hangup).
* Dial end messages have been added where they were previously missing.
* Queue stats are properly being updated again once calls have finished.
* AgentComplete stasis messages and AMI events are now occurring again.
* Mixmonitor starting has been factored into its own function and uses the
Mixmonitor API now instead of using ast_pbx_run()
In addition to the changes in app_queue, there are several supplementary changes as well:
* Queue logging now differentiates between attended and blind transfers. A
note about this is in the CHANGES file.
* Local channel optimization events now report more information. This
includes which of the two local channels involved is the destination of
the optimization, the channel that is replacing the destination local channel,
and an identifier so that begin and end events can be matched to each other.
The end events are now sent whether the optimization was successful or not and
includes an indicator of whether the optimization was successful.
* Changes were made to features and bridging_basic so that additional flags may
be set on a bridge. This is necessary because the queue requires that its
bridge only allows move-swap local channel optimizations into the bridge.
(closes issue ASTERISK-21517)
Reported by Matt Jordan
(closes issue ASTERISK-21943)
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2694
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds a virtual table of callbacks to core_unreal. These callbacks can be
supplied by concrete implementations of "unreal" channel drivers, which lets
the unreal channel driver call specific functionality when it performs some
action. Currently, this is done to notify implementations when an
optimization operation has begun, and when an optimization operation has
succeeded.
* It adds Stasis-Core messages for Local channel bridging and Local channel
optimization. Local channel optimization is now two events: a Begin and an
End. Some consumers of Stasis-Core may want to know when an operation is
beginning so that they can 'prepare' their information; others will be more
concerned about when the operation has completed, so that they can 'fix up'
information. Stasis-Core allows for both, as does AMI.
Review: https://reviewboard.asterisk.org/r/2552
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matthew Jordan
Scott Griepentrog
Kevin Harwell
David M. Lee
Mark Michelson
Richard Mudgett
Kinsey Moore