On Wed, Mar 2, 2016 at 12:51 PM, Michael Ulitskiy <mulits...@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@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 > > > > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
