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 sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev