the query in ht_db_load_table is
select key_name,key_type,value_type,key_value from htable order by key_type;
that is records are ordered by key_type, which means that 0 entries come
first and 1 entries after that.
in ht_db_load_table function there is test in the loop:
if(ktype==0 &&
Juha Heinanen writes:
> here you go:
>
> # sip-proxy_ctl mi sht_reload htable
> # sip-proxy_ctl mi sht_dump htable | egrep 20033
> lpi::20033::prefix[0]:: +3583796294
> lpi::20033::prefix[1]:: +35837824030
> lpi::20033::prefix::size:: 1
now when i took closer look at the db table, it actually co
Daniel-Constantin Mierla writes:
> If the value is invalid at startup/reload, then something is wrong,
> indeed.
daniel,
here you go:
# sip-proxy_ctl mi sht_reload htable
# sip-proxy_ctl mi sht_dump htable | egrep 20033
lpi::20033::prefix[0]:: +3583796294
lpi::20033::prefix[1]:: +35837824030
lp
Hello,
On 5/24/11 4:40 PM, Juha Heinanen wrote:
i have entries in htable with key name lpi::20033::prefix:
# sip-proxy_ctl mi sht_dump htable | egrep 20033
lpi::20033::prefix[0]:: +3583796294
lpi::20033::prefix[1]:: +35837824030
lpi::20033::prefix::size:: 1
as you see in above, size of that ke
i have entries in htable with key name lpi::20033::prefix:
# sip-proxy_ctl mi sht_dump htable | egrep 20033
lpi::20033::prefix[0]:: +3583796294
lpi::20033::prefix[1]:: +35837824030
lpi::20033::prefix::size:: 1
as you see in above, size of that key name is 1 although there clearly
is two entries i
Maybe the term entry should be replaced with slot, looks to be more
standard. A good doc about hash tables is on wikipedia:
http://en.wikipedia.org/wiki/Hash_table
The htable module keeps the number of items in a slot, but not exported
via rpc, this could be added in the future.
Ramona
On
2010/10/16 Uriel Rozenbaum :
> What would be best to optimize the system is to have some statistic
> information, save every now and then the status of the htable and act
> accordingly to:
> - If the table is pretty much or completely used and you have
> collisions, make the size parameter bigger
>
On 10/16/2010 09:18 AM, Juha Heinanen wrote:
Uriel Rozenbaum writes:
What would be best to optimize the system is to have some statistic
information, save every now and then the status of the htable and act
accordingly to:
it would indeed be nice of htable module would exports stats about
col
Uriel Rozenbaum writes:
> What would be best to optimize the system is to have some statistic
> information, save every now and then the status of the htable and act
> accordingly to:
it would indeed be nice of htable module would exports stats about
collisions.
-- juha
Iñaki,
Just as an addition from experience on hash tables, the first
"sweet-spot" on the design is to have a fairly good algorithm so that
different keys are mapped on different hash values. You cannot pick
this (as far as I read) but we'll think it as fair enough. What you
can do to "help" the al
Iñaki Baz Castillo writes:
> And those collisions mean that I could look for a key name and
> retrieve another key (as both key names produce the same hash), am I
> right?
no, the values whose keys hash to the same index of hash table, are
added into a linked list and then list list will be searc
2010/10/16 Juha Heinanen :
> size=4 means that the hash table has 16 entries. it does not mean that
> the table could not contain more objects, but collisions will happen.
And those collisions mean that I could look for a key name and
retrieve another key (as both key names produce the same hash)
Iñaki Baz Castillo writes:
> Hi, in the doc of HTable module all the examples show "a=>size=4;". As
> the doc says:
>
> size - number specifying the size of hash table. The number of entries in
>the table is 2^size
>
> This is, the examples just allow 16 concurrent entries, which i
Hi, in the doc of HTable module all the examples show "a=>size=4;". As
the doc says:
size - number specifying the size of hash table. The number of entries in
the table is 2^size
This is, the examples just allow 16 concurrent entries, which is not
enough in most of the cases.
Did I m
On Monday 26 April 2010, Alex Balashov wrote:
> > There is probably a certain point on which further increase of the htable
> > size make not that much sense anymore. It seems the module only supports
> > from 256 to 16384 buckets in the htable. So depending on the distribution
> > of the hash func
On 04/26/2010 07:48 AM, Henning Westerholt wrote:
On Monday 26 April 2010, Alex Balashov wrote:
i think this is a static setting, as the memory is allocated on startup
in shared memory. Do you've run into performance problems or memory size
constraints with the htable module?
None whatsoever,
On Monday 26 April 2010, Alex Balashov wrote:
> > i think this is a static setting, as the memory is allocated on startup
> > in shared memory. Do you've run into performance problems or memory size
> > constraints with the htable module?
>
> None whatsoever, I was just curious from a theoretical
On 04/26/2010 07:31 AM, Henning Westerholt wrote:
On Monday 26 April 2010, Alex Balashov wrote:
The htable size is static; it doesn't dynamically resize itself up to
the next power of 2 after a certain utilisation threshold, right?
Hi Alex,
i think this is a static setting, as the memory is
On Monday 26 April 2010, Alex Balashov wrote:
> The htable size is static; it doesn't dynamically resize itself up to
> the next power of 2 after a certain utilisation threshold, right?
Hi Alex,
i think this is a static setting, as the memory is allocated on startup in
shared memory. Do you've
The htable size is static; it doesn't dynamically resize itself up to
the next power of 2 after a certain utilisation threshold, right?
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web:
20 matches
Mail list logo
