6 Oct
2008
6 Oct
'08
1:27 p.m.
On Tuesday 30 September 2008, Daniel-Constantin Mierla wrote:
Hi Alex,
don't that much about the dispatcher internals, but i think it also uses the
CRC32 hash. In my tests with the carrierroute module that uses this too,
requests over a random callid/ from user are distributed equally with about
+/- 5% accuracy, which i think is ok. If you need to adjust the target host
distribution, take a look at the hash_id functionality (carrierroute config
file mode), here you can specify the exact destination. We use also the this
approach of pre-calculating the hash value that Daniel described.
Cheers,
Henning
[..]
Sure, it's great if my registrants always go to the same location
server, but if 90% of my users end up going to one location server
because of the distribution that the variance of their From URIs
provides, what does this really give me except a predictable route?
It's not as if I can use the hash to "find" a user's location server
-- unless the location server was determined using the same hash also.
What's the point?
The hash function was tested to get pretty fair distribution for AoR,
most of the hashed values respect this format. If 90% of your users end
up to same server, then you may need to code a bit :-) and add an
alternative hash function to the module. For me the existing one seems
good so far.
I do not need to know where a user call is going. Practically, they
could share the same db backend for auth, but the location and other
user profiles details may be in memory for speed purposes. In what I am
doing, all the servers in a group have same config, if i add a new one,
I get a new dispersion of the users across servers.
Getting the distribution is quite simple, take the has function and make
a simple app that takes as parameter a string and outputs the hash
value. Knowing your subscriber base ids, you can estimate the results of
dispatching.