2 Feb
2010
2 Feb
'10
8:41 p.m.
Hello Henning,
Having both method of initialization will just complicate the code.
When the module parameters are parsed, the shared memory is not
available and therefor all the module rate limit parameters will need
to be cached into the memory until the shared memory is available.
New code needs to be added to deal with conflicts when both method of
initialization are provided: init via db and init via module
parameters.
Having the ratelimit configured via module parameters is forcing
changing the config file every time the default rate limits are
changed.
Using the simple db_text module has a lot of advantages:
- db_text is available for all platforms;
- the database is used only during init, after that the database is
no longer used and therefor there is no impact on performance;
- the rate limits are stored in human readable text file;
- a database reload feature can be added and the default rate limits
can be changed without touching the config file and server restart
will keep the new settings.
These are just my observation from using heavily the existing ratelimit module.
If specifying the rate limits in the config file is a must, I would
recommend keeping both modules and moving the common code into a
library:
- ratelimit with config init
- pipelimit with db init
Regards,
Ovidiu Sas
On Tue, Feb 2, 2010 at 10:32 AM, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
On Monday 01 February 2010, Jan Janak wrote:
Yes, from what I have seen having load balancers without database is
common. Right now we could probably use db_text module for such setups.
Hi Jan,
yes, this could be used, of course. But for now i'd like to keep the old
simple setup with just a configuration file. ;)
I'm in favor of keeping this module as a db only
module. Combining
both init methods (param and db config) is messy due to the current
module initialization (the shm mem is not available during the param
parsing). For small/embedded systems db_text is always a viable
alternative.
Hello Ovidiu,
i did not reviewed the code yet, but some people also like to run their
balancers without a database to avoid this additional complexity. In the future having a driver for Sqlite or
berkeleydb would be a better
option. Both Sqlite and Berkeley DB databases appear to be reasonably fast
for such setups and they require no special or complicated setup.
There is a native berkeleydb driver in kamailio, and I used sqlite for testing
with the db_unixodbc driver, but i'm not sure how the state of this is now in
the sip-router repository. Marius, did you tested the unixodbc cases with the
unit tests?
Henning
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users