Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Why have 5 throttle levels if Drupal core only cares about levels 0 and 5? Contrib code may pay attention to usage levels between 0 and 5, but I have not found anything in core that does so. This series of patches introduces the ability to set -- per module and per block -- the throttle level at which the module or block is disabled.
This is not a complicated patch, IMHO. It simply replaces the check boxes with selects and adjusts two logical comparisons against the current throttle status. The patch affecting block.module is big only because it cleans up the code for legibility.
This is a multi-part patch. This file modifies system.module. The next files will modify block.module and module.inc and provide updated help text. The help text patch will come later today.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | throttle.help.patch | 7.98 KB | njivy |
| #3 | throttle.fine_control.block_system.patch | 4.11 KB | njivy |
| #2 | throttle.fine_control.block.patch | 2.93 KB | njivy |
| #1 | throttle.fine_control.module.patch | 663 bytes | njivy |
| throttle.fine_control.system.patch | 1.18 KB | njivy |
Comments
Comment #1
njivy commentedpatch for module.inc
Comment #2
njivy commentedpatch for block.module
Comment #3
njivy commentedIMO, the UI looks cleaner if the top item in the select drop-downs is a space ( ) instead of a hyphen (-). Less chart-junk.
This patch replaces the patches for block.module and system.module. Perhaps I should have combined files earlier ... :P
Comment #4
njivy commentedpatch for help documentation
Comment #5
Stefan Nagtegaal commentedCouldn't you update your patch and make the 'throttle'-row in the table dissapear when the throttle.module is not enabled? This would be a significant usability improvement.. there are several feature requests for this for a long, long time!
Comment #6
Stefan Nagtegaal commentedAnd please do the same for the system.module which also adds a 'throttle'-row inside the modules enabled/disabled overview table..
Comment #7
dries commentedDo you _really_ have a need to make it that configurable? I think the enable/disable-toggle is just fine. It keeps things (relatively) simple.
Comment #8
njivy commentedDo I need this? Well, I have not yet been slashdotted if that's what you mean.
As I see it, the arguments for and against this patch boil down to performance vs. simplicity. On one hand, this patch allows a site to react to mini-surges before they become tsunami-like slashdot catastrophes. On the other hand, the site administrator doesn't need to spend an extra minute thinking about the difference between 1 and 5. There is only a checkbox.
I prefer the ability to control the site in the event of an oncoming usage spike. Personally, I think the extra minute spent looking at the new controls will be well spent.
Comment #9
jeremy commentedWhy have 5 throttle levels if Drupal core only cares about levels 0 and 5?Multiple levels are helpful when trying to properly tune the throttle. If there was only "ON" and "OFF", it'd be more difficult to measure a normal load, watching it ramp up, detecting spikes. To get a better idea for how the throttle is configured and intended to function, read these instructions. This shows how to properly tune this functionality specifically with Slashdot in mind, and explains how to use the various levels. This functionality was tested multiple times on a live site receiving links from Slashdot, and did indeed work.
For what it's worth, when I originally wrote the throttle code it allowed you to fine tune the same way your patch does, and more. This was deemed too confusing, and hence it was simplified into what's in core today. Based on feedback I've received from users of this functionality, I think it's best to keep it as is.
Comment #10
Deno commentedPersonally I would find it easier to think in terms of "how important is this module for your site", than in terms of "trottle levels".
Thus, instead of asking "which trottle level you want", why not ask the user something like:
"In case of overload, we could try disabling some less important features, thuis giving the site greater chance of survival. Please choose the level of importance for each module"
Then present a pull-down menu with choices "Must have", "Very important", "less important", "unimportant" & "optional" (or such).
Giving some sane default level for each module would also be a good idea...
WDYT?
Comment #11
jonbob commentedComment #12
dries commentedI think Deno has a point but I'd rather stick with 'enable' and 'disable' for now. That requires the least amount of thought by the user.