On Tuesday 02 February 2010, Ovidiu Sas wrote:
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.
Hello Ovidiu,
i agree here with you.
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.
This is not a problem when you make this exclusive, either config file or DB mode, like in cr.
Having the ratelimit configured via module parameters is forcing changing the config file every time the default rate limits are changed.
The ratelimit supports changing with FIFO commands.
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;
Well, this is also true for the configuration 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.
discussed above
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:
Hm, it seems that the logic is not that big that moving this to a library is strictly necessary. The complete module is only about 1.5 kLOC. The dbtext module is about 3.5 kLOC, for comparison. In my opinion a switch like "config_mode" could be a good option and should hopefully be not that intrusive in the implementation.
Just some arguments from my side why i not like the dbtext approach that much. We've processes and tools for packaging and deploying our configuration to the servers, we need to adapt documentation and get operational experience with the new database module. So this work i'd like to avoid, especially if I only want to provide a few lines of configuration data. I also don't want to run into eventual corruption problems in the database during an failover situation or a watchdog restart of a loadbalancer.
But, moving a bit away from this argumentation, i thought that this discussion was about an eventual replacement of ratelimit with the pipelimit module? As long as the ratelimit module is available i don't worry about if the pipelimit support only DBs, as we don't have too advanced requirements in this regards.
Best regards,
Henning