[Serdev] Re: [Serusers] Re: usrloc loading

[Jiri Kuthan]

At 08:07 16/12/2006, Martin Hoffmann wrote:
>Same here. Obviously ;-)

well except I'm apparently going to break my records :-(
happy new year, anyhow!

>> I think the most robust solution for this particular problem would be actually 
>> a robust usrloc-specific cache strategy. SER can deal with quite tough load, 
>> jsut flushing in database needs to be done in a safer way. This would appear 
>> to me as a reasonable action to take.
>
>This goes beyond usrloc. SER's worker processes are synchronous in every
>way. They start processing a request and only come back when they are
>finished with it. This is okay since it makes programming much easier
>and generally, you have enough of them anyways. But there will always be
>situations where they will have to wait for something, be it DNS or the
>database, and eventually all of them are used up. Being able to finish
>transactions quickly by 503ing them may help you to get over it.

We have had this debate couple of times too -- at the risk of oversimplifcation,
it is a big hammer approach versus tedious case-by-case work. Even though here
they are not really mutually exclusive.

I think the feature you are suggesting (cancel-if-it-takes-too-long for whatever
reason) could be reasonable self-recovery tool. I think that in addition to that
going through the code case-by-case is unavoidable so that we dont have to
503 unnecessarily. Usrloc the way mentioned before, database by use of fast
databases (like TimesTen), etc. DNS is harder as it depends on things which
are out of our control, that's why the new DNS code has some specific timers
in it.

>> well -- aliases via usrloc was kind of temporary solution which stayed
>> longer than planned :-)
>
>I actually like it. 

That's embarassing to me :-) I consider it a great feature not to have it any
more. One of the reasons is that aliases are actually provisoned data whereas
usrloc is kind of temporary data (or session data, web folks could say). In
highly optimized systems you may use completely different data processing
techniques. Then it is unfortunate if the provisoned alias data is treated 
using data tools for temporary data.

>More so, I recommend using usrloc for call
>forwarding as well. The advantage over AVPs is that you can have more
>than one address to forward to (aka parallel hunting).

I think you can have it with AVPs as well.

>> >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).
>> 
>> indeed, but its read-and-write nature makes it somewhat peculiar.
>
>Not necessarly. In a large installation you may want to split the
>servers into separate registrars and location service machines.
>
>Which is yet another scenario that is impossible with usrloc caching.
>The cache just simply forces you to use a very specific solution for
>high availability and load balancing. If it is optional, I can analzye
>my traffic and decide what fits me best.

It is true that it narrows down the solution space, I just kind of happen
to think that it is the subspace which is of interest in optimized systems.
The thing is that in critical situations, fully fledged database system
for "aggressive" session data will very easily fly apart -- I think it is
safer to capture stress in front of the network before it propagates
further.

A bit esthetic discussion, I admit.


>> >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.
>> 
>> I am not sure. It helps to absort retransmissions but I think we can
>> go beyond that in a more robust way: if we do usrloc more robust as such
>> (works even for non-retranmissions) and it won't even cost TM memory.
>
>No need to worry about that. For us, the memory ends somewhere around
>30,000 transactions. If you have that many, something went seriously
>wrong.
>
>> >Providing that data fast enough is the job of the
>> >database.
>> 
>> True, even though I learned to prefer not to rely blindly on magic databases :-)
>> I think there is couple of things one may do:
>> - optimization of the application -- even superperfect database will be killed
>>   by superdumb app. a particular feature I'm thinking of is even smarter usrloc
>>   cache which serves more extensively its buffer purpose to database behind it.
>
>Still not convinced. What do you do if the content of the database
>changes?
>
>> - network design for the database. There are many ways to do these things and
>>   what I think just doesn't work is blind trust in xyz's database-cluster
>>   software.
>
>I'd rather leave this to the people designing the particular
>infrastructure. They know their setup best and can decide whether a
>clustered database or a collection of replicates or something else
>entirely suits them best.

Could be. Our observations have been that session data have very explosive
potential and it is safer to throttle explosions earlier than too late.



>>   Some of the optimizations can be actually done in front of
>>   database. (E.g., in some setups usrloc data never goes to database, it is
>>   just shared via a bus through all SER instances).
>
>Maybe "database" is the wrong word here. Indeed, what usrloc needs is a
>data store that allows data to be shared between different machines.

I agree.

> A
>database is the most simple way to set this up. 

That's a broad term. Just taking off-the-shelve DB cluster, which I would hope for,
works typically less optimally than one may hope based on DB/cluster whitepapers.

Again -- I think this is interesting what-if academic conversation but if you think there
is some design error which precludes some working scenario, highlite it for me.

-jiri

>There may be other
>choices available.
>
>Regards,
>Martin

--
Jiri Kuthan            http://iptel.org/~jiri/