Skip to content
Snippets Groups Projects
  • Matthew Jordan's avatar
    e7d49d28
    Fix a performance problem CDRs · e7d49d28
    Matthew Jordan authored
    There is a large performance price currently in the CDR engine. We currently
    perform two ao2_callback calls on a container that has an entry for every
    channel in the system. This is done to create matching pairs between channels
    in a bridge.
    
    As such, the portion of the CDR logic that this patch deals with is how we
    make pairings when a channel enters a mixing bridge. In general, when a
    channel enters such a bridge, we need to do two things:
     (1) Figure out if anyone in the bridge can be this channel's Party B.
     (2) Make pairings with every other channel in the bridge that is not already
         our Party B.
    
    This is a two step process. In the first step, we look through everyone in the
    bridge and see if they can be our Party B (single_state_process_bridge_enter).
    If they can - yay! We mark our CDR as having gotten a Party B. If not, we keep
    searching. If we don't find one, we wait until someone joins who can be our
    Party B.
    
    Step 2 is where we changed the logic
    (handle_bridge_pairings and bridge_candidate_process). Previously, we would
    first find candidates - those channels in the bridge with us - from the
    active_cdrs_by_channel container. Because a channel could be a candidate if it
    was Party B to an item in the container, the code implemented multiple
    ao2_container callbacks to get all the candidates. We also had to store them
    in another container with some other meta information. This was rather complex
    and costly, particularly if you have 300 Local channels (600 channels!) going
    at once.
    
    Luckily, none of it is needed: when a channel enters a bridge (which is when
    we're figuring all this stuff out), the bridge snapshot tells us the unique
    IDs of everyone already in the bridge. All we need to do is:
     For all channels in the bridge:
       If the channel is us or our Party B that we got in step 1, skip it
       Compare us and the candidate to figure out who is Party A (based on some
           specific rules)
       If we are Party A:
          Make a new CDR for us, append it to our chain, and set the candidate as
              Party B
       If they are Party A:
          If they don't have a Party B:
            Make a new CDR for them, append us to their chain, and us as Party B
          Otherwise:
            Copy us over as Party B on their existing CDR.
    
    This patch does that.
    
    Because we now use channel unique IDs to find the candidates during bridging,
    active_cdrs_by_channel now looks up things using uniqueid instead of channel
    name. This makes the more complex code simpler; it does, however, have the
    drawback that dialplan applications and functions will be slightly slower as
    they have to iterate through the container looking for the CDR by name.
    That's a small price to pay however as the bridging code will be called a lot
    more often.
    
    This patch also does two other minor changes:
     (1) It reduces the container size of the channels in a bridge snapshot to 1.
         In order to be predictable for multi-party bridges, the order of the
         channels in the container must be stable; that is, it must always devolve
         to a linked list.
     (2) CDRs and the multi-party test was updated to show the relationship between
         two dialed channels. You still want to know if they talked - previously,
         dialed channels were always ignored, which is wrong when they have
         managed to get a Party B.
    
    (closes issue ASTERISK-22488)
    Reported by: Richard Mudgett
    
    Review: https://reviewboard.asterisk.org/r/2861/
    ........
    
    Merged revisions 399666 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399667 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    e7d49d28
    History
    Fix a performance problem CDRs
    Matthew Jordan authored
    There is a large performance price currently in the CDR engine. We currently
    perform two ao2_callback calls on a container that has an entry for every
    channel in the system. This is done to create matching pairs between channels
    in a bridge.
    
    As such, the portion of the CDR logic that this patch deals with is how we
    make pairings when a channel enters a mixing bridge. In general, when a
    channel enters such a bridge, we need to do two things:
     (1) Figure out if anyone in the bridge can be this channel's Party B.
     (2) Make pairings with every other channel in the bridge that is not already
         our Party B.
    
    This is a two step process. In the first step, we look through everyone in the
    bridge and see if they can be our Party B (single_state_process_bridge_enter).
    If they can - yay! We mark our CDR as having gotten a Party B. If not, we keep
    searching. If we don't find one, we wait until someone joins who can be our
    Party B.
    
    Step 2 is where we changed the logic
    (handle_bridge_pairings and bridge_candidate_process). Previously, we would
    first find candidates - those channels in the bridge with us - from the
    active_cdrs_by_channel container. Because a channel could be a candidate if it
    was Party B to an item in the container, the code implemented multiple
    ao2_container callbacks to get all the candidates. We also had to store them
    in another container with some other meta information. This was rather complex
    and costly, particularly if you have 300 Local channels (600 channels!) going
    at once.
    
    Luckily, none of it is needed: when a channel enters a bridge (which is when
    we're figuring all this stuff out), the bridge snapshot tells us the unique
    IDs of everyone already in the bridge. All we need to do is:
     For all channels in the bridge:
       If the channel is us or our Party B that we got in step 1, skip it
       Compare us and the candidate to figure out who is Party A (based on some
           specific rules)
       If we are Party A:
          Make a new CDR for us, append it to our chain, and set the candidate as
              Party B
       If they are Party A:
          If they don't have a Party B:
            Make a new CDR for them, append us to their chain, and us as Party B
          Otherwise:
            Copy us over as Party B on their existing CDR.
    
    This patch does that.
    
    Because we now use channel unique IDs to find the candidates during bridging,
    active_cdrs_by_channel now looks up things using uniqueid instead of channel
    name. This makes the more complex code simpler; it does, however, have the
    drawback that dialplan applications and functions will be slightly slower as
    they have to iterate through the container looking for the CDR by name.
    That's a small price to pay however as the bridging code will be called a lot
    more often.
    
    This patch also does two other minor changes:
     (1) It reduces the container size of the channels in a bridge snapshot to 1.
         In order to be predictable for multi-party bridges, the order of the
         channels in the container must be stable; that is, it must always devolve
         to a linked list.
     (2) CDRs and the multi-party test was updated to show the relationship between
         two dialed channels. You still want to know if they talked - previously,
         dialed channels were always ignored, which is wrong when they have
         managed to get a Party B.
    
    (closes issue ASTERISK-22488)
    Reported by: Richard Mudgett
    
    Review: https://reviewboard.asterisk.org/r/2861/
    ........
    
    Merged revisions 399666 from http://svn.asterisk.org/svn/asterisk/branches/12
    
    
    git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399667 65c4cc65-6c06-0410-ace0-fbb531ad65f3