Some remarks and eventual corrections. On 25/02/15 08:50, Olle E. Johansson wrote: > Yesterday I used the UAC module to register 10.000 accounts while testing a > platform. I guess this is something it wasn't built for. I just wanted to add > some notes to the archives about this: > > - The module seems to read all 10.000 entries from the database in one go and > then add them to shared memory. > It may be good for the future to limit the amounts of records for each read > and take it in multiple batches (other modules > have this functionality).
This should be in place already, fetching 1000 records (not 10 000). Maybe that should be made a module parameter -- I guess it was intended so because is defined as a variable, just not exported to module params. > > - The module registers all at once, it's very fast. I think we could add a > throttle and register in batches in the future. I thought at some point about it, an option would be to just add it in memory and 'plant' it there as registered for a short random interval, so the timer will pick it up when appears a 'just to expire'. On the other hand, it means some records won't be actually registered during that interval. So this sounds like a parameter based option to be added. > > - The error handling seems very simple. If something goes bad, we disable the > account. I am not sure if the > TM module will handle failover and retries if we get a 503 with > retry-after. There's no code in uac_reg.c for it. I don't think it does it now, it would be a good addition. > > - There's no different handling of local timeouts and remote 408s. Again, > maybe the TM module handles some > of that. Would it be a difference here? > > - Maybe we need an event route for disabling/enabling registrations. > > I created a branch and added counter support for all database entries, > disabled entries and active entries (working registrations). Pull request > will come :-) Nice, those will be useful, indeed. Cheers, Daniel > > All in all, while this is not a normal use of it, I think it is a very good > tool for testing of new platforms. As usual - Kamailio rocks! > > /O > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
