[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=244211#comment-244211 ] 

Joshua Colp commented on ASTERISK-27983:
----------------------------------------

The log message you are referring to occurs EARLY before it is even treated as a registration, so I have no idea what exactly the interaction was like and what really happened to cause the message. It's not something that would be changed though because it fundamentally has nothing to do with a registration. It's "I got this SIP message, who is it from?".

> 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: Unassigned
>            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)