30 Nov
2006
30 Nov
'06
4:32 p.m.
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]:
Hello,
some confusion was created around this subject. It was pointed a news which was related
to an improvement (fetch support)
which brought memory usage optimization in usrloc (going to be expanded in usage to other
modules, like lcr, presence ...),
not usrloc loading/lookup optimization. It was not yet a news since the work is not fully
finished/well tested. The news
about this new improvements will come in the near future. It started in summer, with:
http://openser.org/pipermail/devel/2006-July/003469.html
Shortly, usrloc records are not loaded anymore by the main process, but by first child.
All other children processes can
handle other events/sip messages in parallel. Previously, at start, OpenSER was blocked
until all records were loaded, which
could be quite long when having big numbers of active users.
Cheers,
Daniel
On 11/30/06 18:58, samuel wrote:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Where is
the time saving coming from then?
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.
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users