[asterisk-bugs] [JIRA] (ASTERISK-27983) pjsip_options: rework may have left concurrency issue

[Joshua Colp (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244208#comment-244208 ] 

Joshua Colp edited comment on ASTERISK-27983 at 7/23/18 7:26 PM:
-----------------------------------------------------------------

You haven't given enough context for this, including how things are configured. Once the config is loaded there isn't really any contention on the endpoint identification process between it and the OPTIONS support. If using a config file then it's an immutable container with no lock, and endpoints themselves have no locks.

[~kharwell] has also been doing some testing and has not seen this kind of result with PJSIP. In his testing it was able to go further than chan_sip.


was (Author: jcolp):
You haven't given enough context for this, including how things are configured. Once the config is loaded there isn't really any contention on the endpoint identification process between it and the OPTIONS support.

[~kharwell] has also been doing some testing and has not seen this kind of result with PJSIP. In his testing it was able to go further than chan_sip.

> pjsip_options: rework may have left concurrency issue
> -----------------------------------------------------
>
>                 Key: ASTERISK-27983
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27983
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 13.22.0
>         Environment: Ubuntu, Asterisk 13.22.0, pjsip, thousands of endpoints
>            Reporter: Gregory Massel
>            Assignee: Gregory Massel
>            Severity: Minor
>              Labels: pjsip
>
> Following the excellent work done in terms of ASTERISK-26806, I have been doing some performance testing on Asterisk 13.22.0 with res_pjsip.
> If I get sipp to run more than 200 registrations per second, it starts logging:
> res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"[redacted]" <sip:[redacted]>' failed for '[redacted]:5060' (callid: [redacted]) - No matching endpoint found after X tries in 0.000 ms
> Where X is between 5 and 9 and >99% of the log entries show 0.000 ms.
> At first I thought the time was logging incorrectly, but there are a few up to 2.731ms.
> It is odd, however, that the endpoint cannot be found after numerous tries in such a short period of time (almost always less than 0.001ms). All the endpoints are valid and, if I reduce the registration rate to 100 reg per second, no such errors log.
> Throughout this, CPU usage remains extremely modest across all cores.
> This leads me to believe that there may be some sort of locking or contention across the endpoints/aors/contacts tables that is causing the registration performance to be restricted in spite of the hardware.
> It seems that, despite significant gains in performance since ASTERISK-26806 was resolved, pjsip is still performing slower than chan_sip in terms of registrations (despite chan_sip using only a single core and res_pjsip threading across 8 cores).



--
This message was sent by Atlassian JIRA
(v6.2#6252)