[asterisk-dev] Asterisk Segfault After PJSIP Commit 5241

[George Joseph]

On Wed, Mar 2, 2016 at 12:51 PM, Michael Ulitskiy <mulitskiy at acedsl.com>
wrote:

> Hello,
>
>
>
> Since you started to look at it again, let me repeat myself.
>
> The problem is described in detail here:
> http://lists.digium.com/pipermail/asterisk-dev/2015-October/075128.html
>
> It has to do with the fact that at initial load pjsip realtime issues
> separate db query for each endpoint/aor/etc in the system.
>
> In my case of ~10K endpoints it took asterisk ~1.5minutes to load.
>
> Further in that discussion I suggested that having the following API call
> to populate sorcery cache would go a long way to
>
> reducing the scale of this problem:
>
>
>
> ast_sorcery_retrieve_by_fields(sip_sorcery,
> "endpoint",AST_RETRIEVE_FLAG_MULTIPLE | AST_RETRIEVE_FLAG_ALL, NULL);
>
>
>
> I haven't looked at pjsip since the time of that discussion as that's
> clearly a show-stopper for me, but I doubt anything changed.
>
> Also I haven't received any feedback if that suggestion is viable, so I'd
> love to hear your (and/or other developers) opinion on it.
>
> Any other idea on how to deal with it is more than welcome as well.
>

​So part of this I just fixed in review 2312.  The cache is now populated
at startup.  Together with full_backend_cache there should be *some*
relief.

One of the base issues however is that we can't use the power of SQL to
narrow down the result set before shipping them all back to Asterisk
because not all the backends support SQL.  If they did, we could, for
instance, 'select * from ps_endpoints a, ps_aors b where a.id = b.id and
b.qualify_frequency > 0' (well almost) to get only the endpoints that need
to be scheduled.  Or 'select * from ps_endpoints where id in
('user','user at domain')'.  We just can't do that right now.

All is not lost however.  We've been noodling with some ideas on how to
make this work more efficiently but it's not something that's going to
happen this week, :)


>
>
> Thanks,
>
> Michael
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160302/304ef865/attachment.html>