[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serdev
Subject:    [Serdev] Re: [Serusers] Re: usrloc loading
From:       Martin Hoffmann <hn () nvnc ! de>
Date:       2006-12-16 7:07:08
Message-ID: 20061216070708.GA24441 () m ! hq ! telio ! no
[Download RAW message or body]

Salut,

Jiri Kuthan wrote:
> 
> sorry for latency, it just appears that emails with content stay in my mailbox
> longer till I find some good time to read them :-)

Same here. Obviously ;-)

> At 10:54 05/12/2006, Martin Hoffmann wrote:
> >
> >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.
> 
> 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 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).
> 
> well -- aliases via usrloc was kind of temporary solution which stayed
> longer than planned :-)

I actually like it. 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).
 
> >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.

> >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.

>   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. A
database is the most simple way to set this up. There may be other
choices available.

Regards,
Martin
_______________________________________________
Serdev mailing list
Serdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
[prev in list] [next in list] [prev in thread] [next in thread]