XF 2.2 Do Xenforo Crons cause any performance impact to the end user?

[Dannymh]

Hi,

I am just about to start writing an hourly task that will run and generate a bunch of things via REST API to another service. This might look like requests with 50 items in it that first need to be collated and placed into batches, the service on the other end will collate these and do what it needs to do.

Anyway my question here is if I use a xenforo cron task for this, will the user who triggers that cron task be effected by any kind of load or performance issue whilst that task is completed?

If so I will just need to move this to a server side cron task that runs as needed. If it jsut triggers the cron and the user isnt effected in anyway then thats fine I will just run with that

 

[Paul B]

The visitor who triggers the cron won't be affected any more than any other visitors.

 

[Sim]

Hi,

I am just about to start writing an hourly task that will run and generate a bunch of things via REST API to another service. This might look like requests with 50 items in it that first need to be collated and placed into batches, the service on the other end will collate these and do what it needs to do.

Anyway my question here is if I use a xenforo cron task for this, will the user who triggers that cron task be effected by any kind of load or performance issue whilst that task is completed?

If so I will just need to move this to a server side cron task that runs as needed. If it jsut triggers the cron and the user isnt effected in anyway then thats fine I will just run with that

Suggestions:

1) use jobs to manage tasks that may take some time to complete, especially if the processing can be done in interruptable batches (ie process first X items, then next execution, process next X items, etc) - the job system is designed to make this easy. A XenForo cron is fine for simple/quick operations, but anything that can take a while to complete, look at using jobs instead. Usually I use a cron task to trigger a job that then does the actual work.

2) if you want more control and to disassociate cron tasks with user activity, change the "Job run trigger" option to "Server based trigger" and use a server cron task (ie crontab or cron.d on unix systems):



3) If you want even more control and/or help testing or debugging your cron tasks and jobs, take a look at my CLI Job / Cron Runner addon - it's generally redundant now that we have Server based trigger options in the core, but my addon does a few extra things that the core version doesn't, which can be handy for debugging issues.

 

[Dannymh]

Suggestions:

1) use jobs to manage tasks that may take some time to complete, especially if the processing can be done in interruptable batches (ie process first X items, then next execution, process next X items, etc) - the job system is designed to make this easy. A XenForo cron is fine for simple/quick operations, but anything that can take a while to complete, look at using jobs instead. Usually I use a cron task to trigger a job that then does the actual work.

2) if you want more control and to disassociate cron tasks with user activity, change the "Job run trigger" option to "Server based trigger" and use a server cron task (ie crontab or cron.d on unix systems):

View attachment 292499

3) If you want even more control and/or help testing or debugging your cron tasks and jobs, take a look at my CLI Job / Cron Runner addon - it's generally redundant now that we have Server based trigger options in the core, but my addon does a few extra things that the core version doesn't, which can be handy for debugging issues.

Is there some more info or developer docs on Jobs v Cron?

How are jobs triggered, are they triggered by the cron (and can be server side, or are they triggered some other way?

 

[Sim]

Is there some more info or developer docs on Jobs v Cron?

How are jobs triggered, are they triggered by the cron (and can be server side, or are they triggered some other way?

I don't know if there is any documentation or if anyone has written a tutorial yet.

Have a look at the jobs used by the core - you'll find them in /src/XF/Job. The restartable jobs can be a bit complicated, but if you look at enough of them, you should be able to work out how they work.

The jobs are usually triggered either by user action (eg sending mail via the mail queue as a result of a user action), or via the cron.

If you take a look at the core cron jobs in /src/XF/Cron, you'll see most of them will simply enqueue a job and don't do any work themselves.

 

[Dannymh]

I don't know if there is any documentation or if anyone has written a tutorial yet.

Have a look at the jobs used by the core - you'll find them in /src/XF/Job. The restartable jobs can be a bit complicated, but if you look at enough of them, you should be able to work out how they work.

The jobs are usually triggered either by user action (eg sending mail via the mail queue as a result of a user action), or via the cron.

If you take a look at the core cron jobs in /src/XF/Cron, you'll see most of them will simply enqueue a job and don't do any work themselves.

Thanks mate appreciate it.

Didn't realise propertychat was your site, I use it regularly good community

 

[Sim]

I think as a general rule, if your task will potentially take more than a few seconds to complete and can be broken into chunks, then a job is the ideal mechanism to run them.

 

[Dannymh]

I think as a general rule, if your task will potentially take more than a few seconds to complete and can be broken into chunks, then a job is the ideal mechanism to run them.

yeah I think its more that it has to be broken down into chunks rather than need to be.

Essentially I am going to create invoices with a 3rd party, they advise 50 per call. In the beginning it will only be a few and less than the 50 in one chunk, so will be quick, single call and move on. But by February I picture this being 200 or more per call especially at a given hour of the day. So sometimes the job running will be almost nothing to lots depending on the hour of the day.

job sounds safer for the extreme use cases and better to get it right now, than try to revisit it later

 

[duderuud]

...

3) If you want even more control and/or help testing or debugging your cron tasks and jobs, take a look at my CLI Job / Cron Runner addon - it's generally redundant now that we have Server based trigger options in the core, but my addon does a few extra things that the core version doesn't, which can be handy for debugging issues.

I use it for my staging server that doesn't get any visitors so the server trigger doesn't work.
Very handy!

 

[James]

I use it for my staging server that doesn't get any visitors so the server trigger doesn't work.
Very handy!

Server trigger should work? It's time based not visitor based.

 

[Sim]

Server trigger should work? It's time based not visitor based.

Pretty sure he meant the "Activity based trigger" doesn't work on a staging server that doesn't get any visitors.