On Thu, Mar 3, 2016 at 2:32 PM, Michael Ulitskiy <[email protected]> wrote:
> George, > > That's really a great news. I guess I should look at pjsip again then. > > Just one question though. I tried to google "full_backend_cache" option, > but all I was able to find > > is commit message in asterisk-commits list and that message isn't very > informative. > > Can you please explain how it's supposed to be used and what it suppose to > do? > > If there's any documentation that explains it, please point me there. > > Thanks a lot, > > Michael > > > It's on my list to update the Wiki. Here's a sorcery.conf example for endpoints... endpoint/cache=memory_cache,object_lifetime_stale=3600,object_lifetime_maximum=28800,expire_on_reload=yes,full_backend_cache=yes endpoint=realtime,ps_contacts In the normal cache scenario, only direct lookups by id are cached. With full_backend_cache, all lookups are cached including those that do a 'get all' like the retrieve all to find qualifyable contacts. > On Wednesday, March 02, 2016 05:08:51 PM George Joseph wrote: > > > On Wed, Mar 2, 2016 at 12:51 PM, Michael Ulitskiy <[email protected]> > > > 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 >
-- _____________________________________________________________________ -- 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
