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