3 Feb
2010
3 Feb
'10
8:01 p.m.
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
--
I'm going to FOSDEM
6. - 7. Februar, Brussels