Forum Discussion
MVPReliability of [after -periodic]?
Hi Folks,
I would like to implement an out-of-band management task using the
[after $time -periodic { script }]I've already used this command in the past for some shortliving and also somewhat unimportant tasks. My current scenario would be an longtime task (aka. forever!) and also somewhat important task, where the health of the entire system would depend on the reliable execution of the provided script.
when RULE_INIT {
after 86400000 -periodic {
Insert some config plane management tasks
}
}
Any experience with
[after -periodic]Do someone have additional information on the performance impact of using such syntax? How many CPU cycles would be required in the background to maintain the "Once Every Day" counter?
Cheers, Kai
13 Replies
If the objective is to perform a periodic task that affects the control plane, then an iCall periodic script may be more sensible.
- Kai_WilkeHi Venon, Thanks for the answer. Its not a configuration change, but still an out-off-band management task that shouldn't consume per-connection/per-request CPU cycles. The performef action is rather simple, i need to issue a [array statistics static::array] command, write a [log] and then unset the static::array variable to release memory. Still strongly recommended to use iCall for this task? Cheers, Kai
VernonWellsEmployee
If the objective is to perform a periodic task that affects the control plane, then an iCall periodic script may be more sensible.
- Kai_WilkeHi Venon, Thanks for the answer. Its not a configuration change, but still an out-off-band management task that shouldn't consume per-connection/per-request CPU cycles. The performef action is rather simple, i need to issue a [array statistics static::array] command, write a [log] and then unset the static::array variable to release memory. Still strongly recommended to use iCall for this task? Cheers, Kai
- VernonWells
For that, you must use an iRule. iCall has no access to that information.
- Kai_WilkeHaven't played much with iCall yet, so i'm glad with this... ;-) Are you able to provide additional infomation/experiences on the relaibility and overhead of a longterm -periodic task? I have to make the decission to use the outlined syntax or continiue to hide the code into a rarely used in-band code path. Any input on this would be much appreciated^^ Cheers, Kai
- VernonWellsI do not, I'm afraid. In general, your best bet is to open an informational case to ask about overhead related to long-term periodic tasks.
- Kai_WilkeHi Vernon, didn't opened a ticket yet. But its seems to run very stable. Cheers, Kai
For that, you must use an iRule. iCall has no access to that information.
- Kai_WilkeHaven't played much with iCall yet, so i'm glad with this... ;-) Are you able to provide additional infomation/experiences on the relaibility and overhead of a longterm -periodic task? I have to make the decission to use the outlined syntax or continiue to hide the code into a rarely used in-band code path. Any input on this would be much appreciated^^ Cheers, Kai
- I do not, I'm afraid. In general, your best bet is to open an informational case to ask about overhead related to long-term periodic tasks.
- Kai_WilkeHi Vernon, didn't opened a ticket yet. But its seems to run very stable. Cheers, Kai
- Kai_Wilke
Hi Folks,
I'd like to update this post, since I'm able to provide long time experinces for the
syntax during[after -periodic]
.RULE_INITwhen RULE_INIT { after 86400000 -periodic { Insert some config plane management tasks } }It works just like a blast and can be considered as very stable.
Cheers, Kai
