[SOLVED] LazyCron possible on every page load, or other technique?

[nurkka]

The shortest time between two LazyCron runs seems to be 30 seconds.
Is there a way to let a LazyCron script run on every page load instead?

If not, what would be a good technique to run a script on every page load, but outside of the normal ProcessWire request context, like LazyCron does? I tried a lot of Hooks, but every one of them kept my script within the current request. I am searching for the right hook or another technique, which let's me run the script in ProcessWire (in a module), but independent from the current request.

Thanks and best regards!

Update: I decided to use a "real" cronjob, which unfortunately can only run every minute, while LazyCron could run every 30 seconds, if your site had enough traffic. If you want to execute a task or parts of a task after every ProcessWire request, you could use the hook ProcessPageView::finished

[wbmnfktr]

Why not combine something like PageRender::renderPage() or whatever is closest to your needs and LazyCron in this case?

Or trigger it with something in your template or a global include.

What do you want to achieve with this?

[BitPoet]

7 hours ago, nurkka said:

I tried a lot of Hooks, but every one of them kept my script within the current request.

Did you try hooking after ProcessPageView::finished? That's what LazyCron does. You may want to add a check for regular page views like LazyCron does here.

[nurkka]

8 hours ago, wbmnfktr said:

What do you want to achieve with this?

 

2 hours ago, BitPoet said:

Did you try hooking after ProcessPageView::finished? That's what LazyCron does. You may want to add a check for regular page views like LazyCron does here.

I want to divide a possibly very long task into small parts, which should be completed relatively quickly. LazyCron leaves at least 30 seconds between two tasks, so I am looking for a way to run the script with every ProcessWire call. In my tests, I got different results when using PageRender::renderPage or ProcessPageView::finished and when the script was executed by LazyCron.

With LazyCron, I got no errors, so I figured, it would be the best way to execute a task, independent from the original request or pageview.

I don't know yet, why my version with ProcessPageView::finished did not work for me - but I will keep testing that.

Thanks for your input!

[poljpocket]

If you are in need of something which runs periodically and the 30s interval is too long, using LazyCron isn't the right way to go. That is not really what it's designed to do.

Remember, 30s is the minimum time in between runs. If your website doesn't see traffic for minutes, the next call to LazyCron will also only be minutes later. This will possibly lengthen your task when you don't see regular traffic (meaning more than one request at least every 30s) and you are splitting it up into small chunks.

For what you are trying to do, you should use the crontab of your server or use an external server which will trigger a Webhook also using it's crontab.

But anyway: Is there any harm in just letting your "long task" do it's thing? Not with LazyCron obviously. I get that this would block one of your visitors every once in a while.

Edited July 24 by poljpocket

[nurkka]

@poljpocket Thanks for your reply! The site has quite good traffic, so LazyCron would be okay in principle.

But no matter if I use LazyCron or the ProcessPageView::finished hook – you mentioned it already – one of the visitors (or, in the worst case, the google bot!) would get a very slow experience.

So I practically have no other choice as to use a real cronjob, which unfortunately can only run every minute.

[poljpocket]

Why unfortunately? You are not blocking any requests this way and so you can just let the task run for as long as it needs. If you have a task which should run every 10 seconds but takes more than 10 seconds, you have a completely different type of problem ?

[nurkka]

On 7/24/2024 at 3:02 PM, nurkka said:

But no matter if I use LazyCron or the ProcessPageView::finished hook – you mentioned it already – one of the visitors (or, in the worst case, the google bot!) would get a very slow experience.

@Robin S posted a possible solution for this here: