[Serusers] Re: usrloc loading

samuel wrote: Numbers obviously depend on your hardware and whether you have a local database. But they are somewhere in the range of 20 seconds for 50,000 entries, 2 minutes for 100,000 entries and 10 minuits for 500,000 entries. Part of the problem and also of the memory usage problem is that the database interface of SER requires that the entire table is slurped into SER's process memory instead of fetching and processing it row by row. This can cause funny behaviour during start-up and a near heart attack for the sysadmin. As far as I understand the announcement (haven't looked at the actual code), the idea is to load everything inside an extra process. The problem with that kind of speed-up is that your responses will not be correct during the loading phase. I am not sure if this is better than being down as it may cause support calls and false problem alerts. If you are in a phase of troubles and have to restart often, this wrong behaviour can go on for hours. But anyways, in my experience with large scale installations, the whole caching thing in usrloc is unnecessary. I have it on good authority that a modern PC can handle more than 100,000 subscribers with a cacheless usrloc and a local database. I once wrote a replacement module that did lookup() directly to the database without any usrloc. It was able to serve substantially more than 100,000 subscribers. (Disclaimer: This actually depends on your usage patterns. I can't provide CPS values, though.) This leaves the registrar stuff. But that is writing to the database anyways. What would be more important here is to have it transactional in a sensible way. They way it works now is that if you have database problems, you delay your response which makes your UAs re-send the request which causes more database troubles. (This, BTW, is true for INVITE processing as well -- here you process your request with all the checks and database lookups and whatnots only to find out upon t_relay() that, oops, re-sent INVITE, needs to be dropped, all for nothing). True, this is not a problem if you use the right db_mode. But there is another issue and that is reliability. At a certain point, you need to have a second SIP server because your superiors read about the five-nine thing. IMHO the easiest way to set this up is by having several servers doing the exact same thing and then load balancing traffic between them. This is only possible if you have a cacheless usrloc and if registrations are written to the database ASAP. So, I do think that this cache is one of those optimizations that look good on paper but in practice are missing the point. That, of course, are just my sixteen øre. And just if someone cares to know, we are using Andreas' usrloc-cl in production and appart from a segfault I introduced while porting in our changes, it runs very smoothly. Regards, Martin