Hello list.
I have a question about the HTABLE module. Suppose that I have a mysql database with 2 million of records. Is possible to load this table as a hash table compatible with Kamailio!?
Hope someone can help me.
Thanks, Ricardo Martinez.-
Anyone here?
Thanks!
Ricardo.-
*De:* Ricardo Martinez [mailto:rmartinez@redvoiss.net] *Enviado el:* miércoles, 14 de agosto de 2013 18:34 *Para:* sr-users@lists.sip-router.org *Asunto:* Hash Table capacity
Hello list.
I have a question about the HTABLE module. Suppose that I have a mysql database with 2 million of records. Is possible to load this table as a hash table compatible with Kamailio!?
Hope someone can help me.
Thanks, Ricardo Martinez.-
According the docs, the hash table is restricted to a maximum size of 2^16 (65536) buckets.
This doesn't mean that the htable can only hold 65k entries, just that it's the maximum number of unique buckets. Assuming a theoretically ideal distribution where every value has a unique bucket, after 65k values, you will get collisions. Collision chains attached to buckets are linear lists. After collision chains get deep, performance becomes more and more linear.
So, you can put 2m values into the htable. I am not sure that it is the optimal use of an htable, however.
Ricardo Martinez rmartinez@redvoiss.net wrote:
Anyone here?
Thanks!
Ricardo.-
*De:* Ricardo Martinez [mailto:rmartinez@redvoiss.net] *Enviado el:* miércoles, 14 de agosto de 2013 18:34 *Para:* sr-users@lists.sip-router.org *Asunto:* Hash Table capacity
Hello list.
I have a question about the HTABLE module. Suppose that I have a mysql database with 2 million of records. Is possible to load this table as a hash table compatible with Kamailio!?
Hope someone can help me.
Thanks, Ricardo Martinez.-
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
Hi,
On 8/19/13 4:05 PM, Alex Balashov wrote:
According the docs, the hash table is restricted to a maximum size of 2^16 (65536) buckets.
it was restricted to 2^14, I just lifted it to positive integer range 2^31 because it is easier to get now systems with plenty of memory -- it will be in next major release.
This doesn't mean that the htable can only hold 65k entries, just that it's the maximum number of unique buckets. Assuming a theoretically ideal distribution where every value has a unique bucket, after 65k values, you will get collisions. Collision chains attached to buckets are linear lists. After collision chains get deep, performance becomes more and more linear.
So, you can put 2m values into the htable. I am not sure that it is the optimal use of an htable, however.
With the previous upper limit (2^14) you could get a fair distribution of about 125 items per slot, which is still fine for linear searching, provided a modern CPU server.
You can simulate some tests and measure the search performances with benchmark module.
Regards, Ramona
Ricardo Martinez rmartinez@redvoiss.net wrote:
Anyone here? Thanks! Ricardo.- *De:*Ricardo Martinez [mailto:rmartinez@redvoiss.net <mailto:rmartinez@redvoiss.net>] *Enviado el:* miércoles, 14 de agosto de 2013 18:34 *Para:* sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> *Asunto:* Hash Table capacity Hello list. I have a question about the HTABLE module. Suppose that I have a mysql database with 2 million of records. Is possible to load this table as a hash table compatible with Kamailio!? Hope someone can help me. Thanks, Ricardo Martinez.- ------------------------------------------------------------------------ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
19 aug 2013 kl. 17:02 skrev Elena-Ramona Modroiu ramona@asipto.com:
Hi,
On 8/19/13 4:05 PM, Alex Balashov wrote:
According the docs, the hash table is restricted to a maximum size of 2^16 (65536) buckets.
it was restricted to 2^14, I just lifted it to positive integer range 2^31 because it is easier to get now systems with plenty of memory -- it will be in next major release.
This doesn't mean that the htable can only hold 65k entries, just that it's the maximum number of unique buckets. Assuming a theoretically ideal distribution where every value has a unique bucket, after 65k values, you will get collisions. Collision chains attached to buckets are linear lists. After collision chains get deep, performance becomes more and more linear.
So, you can put 2m values into the htable. I am not sure that it is the optimal use of an htable, however.
With the previous upper limit (2^14) you could get a fair distribution of about 125 items per slot, which is still fine for linear searching, provided a modern CPU server.
You can simulate some tests and measure the search performances with benchmark module.
When you do, please share the results! - How long time does it take to load/reload such a big hash table?
/O
Regards, Ramona
Ricardo Martinez rmartinez@redvoiss.net wrote: Anyone here? Thanks!
Ricardo.-
De: Ricardo Martinez [mailto:rmartinez@redvoiss.net] Enviado el: miércoles, 14 de agosto de 2013 18:34 Para: sr-users@lists.sip-router.org Asunto: Hash Table capacity
Hello list. I have a question about the HTABLE module. Suppose that I have a mysql database with 2 million of records. Is possible to load this table as a hash table compatible with Kamailio!?
Hope someone can help me.
Thanks, Ricardo Martinez.-
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
19 aug 2013 kl. 17:02 skrev Elena-Ramona Modroiu ramona@asipto.com:
On 8/19/13 4:05 PM, Alex Balashov wrote:
According the docs, the hash table is restricted to a maximum size of 2^16 (65536) buckets.
it was restricted to 2^14, I just lifted it to positive integer range 2^31 because it is easier to get now systems with plenty of memory -- it will be in next major release.
This is so typical of Open Source. Someone highlights a limitation or a problem and moments later a developer fixes it.
Thank you everyone - reporters and developer!
Kamailio has a great team working with the code.
/O
Why isn't htable designed to use separate chains to avoid collisions altogether?
On Mon, Aug 19, 2013 at 11:18 AM, Olle E. Johansson oej@edvina.net wrote:
19 aug 2013 kl. 17:02 skrev Elena-Ramona Modroiu ramona@asipto.com:
On 8/19/13 4:05 PM, Alex Balashov wrote:
According the docs, the hash table is restricted to a maximum size of 2^16 (65536) buckets.
it was restricted to 2^14, I just lifted it to positive integer range 2^31 because it is easier to get now systems with plenty of memory -- it will be in next major release.
This is so typical of Open Source. Someone highlights a limitation or a problem and moments later a developer fixes it.
Thank you everyone - reporters and developer!
Kamailio has a great team working with the code.
/O
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 10/20/2014 11:17 AM, Vik Killa wrote:
Why isn't htable designed to use separate chains to avoid collisions altogether?
Chains do not avoid collisions; they're attached to buckets, and simply represent a particular data structure for handling allocations into the same bucket.
Alex, It is a collision resolution, yes collisions will still happen but it essentially fixes the problem. /V
On Mon, Oct 20, 2014 at 12:13 PM, Alex Balashov abalashov@evaristesys.com wrote:
On 10/20/2014 11:17 AM, Vik Killa wrote:
Why isn't htable designed to use separate chains to avoid collisions
altogether?
Chains do not avoid collisions; they're attached to buckets, and simply represent a particular data structure for handling allocations into the same bucket.
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Fixes the problem, as opposed to what? What about the htable implementation does not satisfy you now?
There are only a few ways of dealing with collisions: put them in a flat list attached to the bucket, devise some algorithm for moving the data to neighbouring buckets, etc. The list approach is by far the most common and straightforward. The best way to minimise collisions entirely is to use a good hash algorithm appropriate to the types of keys being hashed.
On 20 October 2014 12:41:50 GMT-04:00, Vik Killa vipkilla@gmail.com wrote:
Alex, It is a collision resolution, yes collisions will still happen but it essentially fixes the problem. /V
On Mon, Oct 20, 2014 at 12:13 PM, Alex Balashov abalashov@evaristesys.com wrote:
On 10/20/2014 11:17 AM, Vik Killa wrote:
Why isn't htable designed to use separate chains to avoid collisions
altogether?
Chains do not avoid collisions; they're attached to buckets, and
simply
represent a particular data structure for handling allocations into
the
same bucket.
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
Alex, Separate chains (IMO) is the best way to deal with collisions. If this is built in, the does not have to deal with collisions (or even know what they are)...it provides scalability without the user having to do anything. /V
On Mon, Oct 20, 2014 at 12:44 PM, Alex Balashov abalashov@evaristesys.com wrote:
Fixes the problem, as opposed to what? What about the htable implementation does not satisfy you now?
There are only a few ways of dealing with collisions: put them in a flat list attached to the bucket, devise some algorithm for moving the data to neighbouring buckets, etc. The list approach is by far the most common and straightforward. The best way to minimise collisions entirely is to use a good hash algorithm appropriate to the types of keys being hashed.
On 20 October 2014 12:41:50 GMT-04:00, Vik Killa vipkilla@gmail.com wrote:
Alex, It is a collision resolution, yes collisions will still happen but it essentially fixes the problem. /V
On Mon, Oct 20, 2014 at 12:13 PM, Alex Balashov < abalashov@evaristesys.com> wrote:
On 10/20/2014 11:17 AM, Vik Killa wrote:
Why isn't htable designed to use separate chains to avoid collisions
altogether?
Chains do not avoid collisions; they're attached to buckets, and simply represent a particular data structure for handling allocations into the same bucket.
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
correction: "If this is built in, the user does not have to deal with collisions (or even know what they are)...it provides scalability without the user having to do anything."
On Mon, Oct 20, 2014 at 12:55 PM, Vik Killa vipkilla@gmail.com wrote:
Alex, Separate chains (IMO) is the best way to deal with collisions. If this is built in, the does not have to deal with collisions (or even know what they are)...it provides scalability without the user having to do anything. /V
On Mon, Oct 20, 2014 at 12:44 PM, Alex Balashov <abalashov@evaristesys.com
wrote:
Fixes the problem, as opposed to what? What about the htable implementation does not satisfy you now?
There are only a few ways of dealing with collisions: put them in a flat list attached to the bucket, devise some algorithm for moving the data to neighbouring buckets, etc. The list approach is by far the most common and straightforward. The best way to minimise collisions entirely is to use a good hash algorithm appropriate to the types of keys being hashed.
On 20 October 2014 12:41:50 GMT-04:00, Vik Killa vipkilla@gmail.com wrote:
Alex, It is a collision resolution, yes collisions will still happen but it essentially fixes the problem. /V
On Mon, Oct 20, 2014 at 12:13 PM, Alex Balashov < abalashov@evaristesys.com> wrote:
On 10/20/2014 11:17 AM, Vik Killa wrote:
Why isn't htable designed to use separate chains to avoid collisions
altogether?
Chains do not avoid collisions; they're attached to buckets, and simply represent a particular data structure for handling allocations into the same bucket.
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Vik,
What exactly do you mean by "separate chains"? I had assumes you were referring to lists attached to hash buckets.
Alex, Yes, linked-lists attached to a hash bucket. http://en.wikipedia.org/wiki/Hash_table#Collision_resolution
On Mon, Oct 20, 2014 at 2:37 PM, Alex Balashov abalashov@evaristesys.com wrote:
Vik,
What exactly do you mean by "separate chains"? I had assumes you were referring to lists attached to hash buckets.
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi, Is there a way to know or cache the last destination selected from dispatcher list? Thanks in advanced!
Date: Mon, 20 Oct 2014 14:52:38 -0400 From: vipkilla@gmail.com To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] Hash Table capacity
Alex,Yes, linked-lists attached to a hash bucket.http://en.wikipedia.org/wiki/Hash_table#Collision_resolution
On Mon, Oct 20, 2014 at 2:37 PM, Alex Balashov abalashov@evaristesys.com wrote: Vik,
What exactly do you mean by "separate chains"? I had assumes you were referring to lists attached to hash buckets.
Please start a new thread by sending a new e-mail instead of replying to something old and changing the topic. Some people have threaded mailers and this will make them miss your question.
On 20 Oct 2014, at 23:28, Kamrul Khan dodul@live.com wrote:
Hi, Is there a way to know or cache the last destination selected from dispatcher list?
The dispatcher stores the destination in the $du or changes the $ru - depending on which method you use. SImply copy the destination to an $avp and you have it.
/O
-
Alex Balashov -
Elena-Ramona Modroiu -
Kamrul Khan -
Olle E. Johansson -
Ricardo Martinez -
Vik Killa