Users shouldn't have to wait for a background process to finish before their page reloads.
One of the most effective techniques for improving user experience and overall performance on a site is embracing the concept of deferring work; using a request to trigger a background process, rather than executing the process in the request itself.
Making use of the Queued Jobs module is an easy way to get the best out of your site, and it comes bundled in the Search Recipe. On request, you should create a job that performs the task in the background, to be processed when it reaches the front of the queue. In this way, you give instant feedback to the user, and the task is able to be executed in the background—which has less overhead than the web version of the same request. Additionally, you should batch any requests that deal with large data sets or tasks that take a long time to process.
For example, if you have a sign-up form that requires a large amount of processing before sending out a confirmation email, it would likely be a slow process to execute all that in the request - and would provide a poor user experience for the person signing up. Far better would be to add a
ProcessSignUpJob to the Job Queue, immediately return confirmation to the user once the job has been added, and let the queue run the job when it can, in the background. It may mean a small delay in the sending of the email while the job makes its way to the top of the queue, but it provides a much better experience for the user - and reduces the impact on the server.
This also helps to mitigate the impact of Denial of Service (DOS) attacks, as it is much harder to induce load when you remove the processing from the request. The queue ensures sensible distribution of the server resources.
You can see this in action with the Solr Reindex Task - where previously this would execute inside the request and potentially throw an error after timing out, now it adds a
SolrReindexJob to the queue and returns a standard task page.
A cron job is a task that executes on a schedule. For example, the task that executes the jobs in the job queue is called every minute. One of the most common implementations of a cron job is to schedule something to run outside of normal business hours when traffic levels to your site are at their lowest. This means that any intensive work will be executed at a time that will impact the least number of users. There are a lot of ways to tweak the frequency to achieve what you need. This is especially useful if you need to export or import a large amount of data on a schedule.
On Silverstripe Cloud these will need to be added via a Service Desk request; alternatively, you can utilise the CronTask module to retain complete developer control over the jobs. This will then require that a cron job be set up to run the cron tasks, but that means it is a one-off rather than a per-task request.