I think the idea behind was the following: The use case is for big providers with lots of entries in the usrloc database. A restart in such situation might lead to stop in the service for quite a few minutes (i don't recall the numbers) while the server is loading the data. If you split the data in chunks and load it sequentally, you can start serving without interrumption... please, can somebody confirm this assumption(I'm not 100% sure)?? Samuel.

Hi guys This was supposed to be a forward to the serusers list, and not a bounce. Sorry Daniel. -Atle * Daniel-Constantin Mierla <daniel(a)voice-system.ro> [061130 19:28]:

At 18:22 30/11/2006, Daniel-Constantin Mierla wrote: Whats going to happen then if a child x process wants to read a usrloc entry whereas child 1 is not finished reading yet? Thanks! -jiri -- Jiri Kuthan http://iptel.org/~jiri/

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

Salut, Jiri Kuthan wrote: This comment wasn't about the caching per se. The database interface allows you to access all rows as an array. This is rarely if ever needed. If the interface instead had a function a la dbf->get_next_row(), you wouldn't need to slurp a table of thousands of rows into pkg_mem first. Another short-coming of the database API is that you can't do a "where expires < now()". This, however, is only a problem if you teach SER not to delete expired rows from the database and then forget to run the cron job that does it (Reminds me that I owe Atle a cookie for that one). If you have enough of those, the only thing you can do here is starting to 503 them. Just an idea: The problem really is that all UDP processes are stuck waiting for the database and new requests wouldn't get handled (which causes a re-sent storm that eventually kills you). If one counts the processes that are stuck, one can write a function that sends a 503 back if only one or two processes are left. What you forget here is that your database has a query cache (or should have). This one is much better suited for this because it can cope with changes to the database from somewhere else. (We had to use serctl to update aliases which sometimes didn't work. The resulting script that tries to insert the alias, then checks whether it is actually there is quite impressive). Plus, usrloc is actually only one out of two or three querries you do per INVITE: does_uri_exist() is probably done on every one (at least if you have call forwarding) and avp_load() is likely to be done for all incoming calls (That's 0.9, of course, dunno about 0.10 yet). What killed me once wasn't usrloc but the avp_load(). And that was only because the indexes on the table were screwed and the select did a full table scan every time. I think a function "t_go_stateful()" might be enough (and use t_reply() in the registrar). The function checks if a transaction for the request exists and if so, ends processing right away. Otherwise it creates a transaction in a prelimary state. Probably, but in this scenario I have several options to solve this, depending on my actual load. I can start with a central database that is accessed over the net, later switch to an elaborate scheme with replication and finally switch to a MySQL cluster-esque solution. High-performance databases are necessary in other applications, too, and do exist. I am a follower of the old Unix strategy that everything does one thing and one thing only. Providing that data fast enough is the job of the database. Regards, Martin PS: Should we move this to serdev?

Michal Matyska wrote: That takes care of INVITEs. Now a version of save() that uses t_reply() instead of sl_send_reply() is needed. I seem to remember that that isn't too hard. Regards, Martin

Salut, Michal Matyska wrote: Cool. One more reason to switch, then. Regards, Martin

Klaus Darilion wrote: I seem to remember that there were some problems with that. I do not claim to understand tm, but during my feeble attempts to do, I found issues with t_lookup_request() and maybe even t_newtran(). Probably something to do with ACKs and CANCELs. Regards, Martin