[asterisk-dev] [Code Review] Hints and devices from hints moved to ao2_container

reviewboard at asterisk.org reviewboard at asterisk.org
Tue Nov 16 14:29:47 CST 2010


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


This patch is looking really good!


branches/1.8/main/pbx.c
<https://reviewboard.asterisk.org/r/1003/#comment6146>

    I'm not sure string fields provide enough value here to use them.  Since there is only one string in this structure, I would just include it at the end of the structure and allocate enough space for it off of the end of the structure.
    
    struct ast_hintdevice {
        struct ast_hint *hint;
        char hintdevice[1]; /* malloc sizeof(struct ast_hintdevice) + strlen(whatever_is_going_here) */
    };



branches/1.8/main/pbx.c
<https://reviewboard.asterisk.org/r/1003/#comment6147>

    I think there is a more efficient way to implement this operation with astobj2.
    
    First, make your callback do this:
    
        return device->hint == hint ? CMP_MATCH : 0;
    
    Second, use these flags to ao2_callback():
    
        OBJ_NODATA | OBJ_MULTIPLE_OBJ_UNLINK
    
    That should be more efficient than calling ao2_unlink() from within your callback.



branches/1.8/main/pbx.c
<https://reviewboard.asterisk.org/r/1003/#comment6148>

    space after comma



branches/1.8/main/pbx.c
<https://reviewboard.asterisk.org/r/1003/#comment6149>

    spaces around +


- Russell


On 2010-11-16 02:38:59, schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1003/
> -----------------------------------------------------------
> 
> (Updated 2010-11-16 02:38:59)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> handle_statechange in pbx.c has a very great impact on call handling performance. i have noticed this several times and i have written a solution which makes handle_statechange handling 61 times faster.
> 
> i have used the patch (rev. 293802 for 1.4) from russellb and jeffpeeler to also fix a deadlock problem and their part to move hints to an ao2_container.
> 
> after thinking about the best solution IMO iterating through the whole hint list/container to maybe find a hint with a matching device is very expensive way. So i have used a own container for devices which just have a link back to their hint. 
> This means there is a hashed cmp for devices which gives back a multiple object ao2_iterator for all hints, this device, which have a state change, is used in. 
> 
> these devices are not longer limited to any length so its possible to use a hint for 100 peers at once.
> 
> Tilghman Lesher noticed on the dev-list what would happen when a dynamic hint is used. I have tried this with one dynamic hint and subscribe up to 2500 different users on this, several times and it works just fine. If a subscribe for a dynamic hint comes in, a static extension with static appdata is generated which acts like a normal hint so there is no problem on this. 
> 
> 
> Diffs
> -----
> 
>   branches/1.8/main/pbx.c 295123 
> 
> Diff: https://reviewboard.asterisk.org/r/1003/diff
> 
> 
> Testing
> -------
> 
> dialplan reload drops all devices out of the device container and recreate them by their callback list.
> core show hint / hints show all hints also dynamic and their watchers
> 
> 
> loadtests shows the following result:
> 
> orig version: 
> handle_statechange COUNTER: 10009 overalltime: 7041 ms 
> MAX: 365 CPS
> 
> patched version:
> handle_statechange COUNTER: 10009 overalltime: 115 ms
> MAX: 580 CPS
> 
> same setup, same config tested with sipp.
> 
> 
> Thanks,
> 
> schmidts
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101116/f97c1e73/attachment-0001.htm 


More information about the asterisk-dev mailing list