[SR-Users] Maximum feasible size of htable?
bbridges at o1.com
Mon Apr 13 17:17:02 CEST 2015
The average item will be relatively small (10 digits for the key, and 7 to 10 digits for the value), and the quantity will be approximately 300-350 million entries.
I do not expect it to require reloading or updating very frequently. Perhaps once or twice a month.
As far as the wait for it to load, these devices are behind a load balancer and can easily wait for the load to complete before "going live", so that's not that big of a concern.
Brooks Bridges | Sr. Voice Services Engineer
5190 Golden Foothill Pkwy
El Dorado Hills, CA 95762
office: 916.235.2097 | main: 888.444.1111, Option 2
email: bbridges at o1.com<mailto:bbridges at o1.com> | web: www.o1.com<http://www.o1.com/>
From: sr-users [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Daniel-Constantin Mierla
Sent: Monday, April 13, 2015 1:19 AM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Maximum feasible size of htable?
On 11/04/15 00:17, Brooks Bridges wrote:
I have a small-ish project that could benefit from using an htable for storage of very basic data that doesn't change much, and I'd like to get an idea of what the group's experience is with storing larger amounts of data? Something in the 15-20GB range.
Yes I could use Redis, but the idea here is to minimize the amount of dependencies and processing required.
how many items you will have in the hash table, or in other words, how big is the average size of in item in the hash table?
Performances can be improved by adjusting the number of slots.
Another thing to consider is the loading in cache, when kamailio is starting. It can take long when it is a really huge amount of records in the backend, so if you need to restart or reload often, might not worth it. On the other hand, you can add/remove by item from hash table.
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users