On Monday 25 January 2010, Antonio Reale wrote:
you should
upgrade for such features:
- in 1.5.x you can use htable to cache value in shared memory and perhaps
offers what you need
- in 3.0.0 you still have htable, but you have also the global avps, you
can set/get them with $avp(g.name). You can load at startup within route
event_route[htable:mod-init] { ... } via sqlops
I migrated to kamailio 3.0 and I used custom cfg file parameters as
explained here:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#custom_cfg_
file_parameters just simple and clear solution.
At this point there are three possible solution (probably four, using
cfg_db module): htable, global AVPs and custom cfg file parameters.
Can someone give a very brief comparison between the three
implementations? Is one better than the others?
Thanks.
Hi Antonio,
from the performance POV this three ways make probably not that much a
difference, but i'd differ them over the intendent use case:
1. global AVPs
This is the oldest mechanism, i think they were implemented as a list in the
core. In kamailio we moved them to the pseudo-variables, but they still have
certain core parts. I'd use them if you've a smaller set of values to store,
like one or two values you set during startup.
2. htable
This is a mechanism coming from the kamailio side, they implement a hash table
like you probably know from other languages as perl or java. As this implement
a key-value storage which is basically arbitrary large (depending on the
memory) i'd use them to store certain attributes, like the number of failed
authentification per user (as described in the mod docs).
3. custom cfg params
This is a mechanism coming from the SER side, i think. If I understand the
docs correctly i'd use them if i have certain attributes which belong to a
bigger group or class, like a hostname or simliar. Its probably easier to add
structure to your values as if you use the (global) AVPs.
Hope that helps,
Henning