[asterisk-bugs] [JIRA] (ASTERISK-25826) PJSIP / Sorcery slow load from realtime

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-25826:
-----------------------------------

    Status: Open  (was: Triage)

> PJSIP / Sorcery slow load from realtime
> ---------------------------------------
>
>                 Key: ASTERISK-25826
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25826
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Core/Sorcery
>    Affects Versions: SVN, 13.7.2
>         Environment: CentOS 7
>            Reporter: Ross Beer
>            Assignee: George Joseph
>
> Asterisk 13 using PJSIP and Sourcery realtime takes over 25 minutes to load.
> On PJSIP start when using a realtime back-end, a full endpoint query is run that pulls all Endpoints from the database.
> During this time the CLI outputs 'Endpoint XXX is now Unknown' and populates the cache. While this wouldn't be a problem with only a few realtime peers, it does create an issue when there are around 20,000 endpoints defined, causing a very slow start-up.
> Sourcery Cache helps with the realtime queries once started, however there is no need to cache all endpoints at start up as they will be retrieved at the point of access. Much like the old chan_sip realtime.
> Ideally Asterisk 13 / Sorcery should have an option to 'pre-load' all end points which would allow the initial load to be skipped if required.
> I understand that in some situations some platforms will require to load all endpoints for 'qualify' functions however there is no need for this in the current set-up, any peers that do require qualification are stored in the .conf files.
> A discussion and diagnosis have been ongoing via the mailing list and a ticket asked to be raised for this issue.  http://lists.digium.com/pipermail/asterisk-dev/2016-March/075355.html



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