8.12 Background Tasks

Owned by Pernille Marqvardsen
Apr 23, 2024
3 min read

A Background Task is an operation that is run by the system in the background of your work, so as not to force you to wait for the task to complete you are able to continue working while the operation finishes.

The Background Tasks area of risr/assess shows you a comprehensive list of all tasks that been completed by the system and provides details about the task for efficient management and review, this includes a status of the task.

Given the diverse range of actions performed on our server, from user interactions to complex backend processes, it's challenging to specify precisely the number and type of tasks it can handle simultaneously. The server's capacity to manage tasks at any given moment is influenced by a variety of factors, including the complexity of individual tasks, the overall demand on the system, and the dynamic allocation of resources. This variability means that while we design our servers for optimal performance, the exact workload they can support at any single point in time can fluctuate based on real-time conditions and requirements.

To ensure optimal performance and a seamless experience for all users, it's crucial to avoid overloading the server with tasks, particularly during exam periods. Overburdening the server can lead to slower response times and may impact the overall functionality, affecting both administrators and exam participants. We recommend scheduling intensive tasks, such as bulk data processing or large-scale item management, outside of peak exam times. By doing so, we can maintain the server's efficiency and reliability, providing a stable and responsive environment for conducting exams and accessing real-time data.

The risr/assess server handles requests in a number of different ways depending on the urgency and resource requirements of the task.

Front-End Server

The server primarily focuses on user interactions and interface rendering. This includes:

  • Adding and managing exam content

  • Configuring exams and marking responses

  • Viewing results and monitoring exam progress

Performance factors include user volume, task complexity, and server capacity. Examples include:

  • the number of exam administrators on the application,

  • the number of exams in progress and the number of candidates and examiners, and

  • the nature of the exam.

In the context of exams, which often entail the submission of numerous responses, our system initially conducts minimal processing on these responses as soon as they are received. This initial step ensures that the responses can be promptly displayed on the live dashboard, providing real-time feedback and updates. Subsequently, these responses undergo a more thorough processing phase, after which they are properly stored in the database.

Queued Tasks

For more resource-intensive tasks, our server employs a queuing system, allowing it to remain responsive. These tasks include:

  • Bulk transitioning, editing and tagging items

  • Importing and exporting items

  • Importing and exporting user data (Candidates, Examiners and Role Players)

  • Creating examination papers

  • Combining exams

  • Pushing exams

  • Converting, merging and removing remote OSCE video files

  • Importing and exporting results and statistics

  • Creating reports (e.g. candidate feedback reports, emailing candidates, item response reports, item cut score reports, Rasch reports, examiner statistic reports, exam analysis reports, marking reports, etc)

These tasks are managed on a first-come, first-served basis, with their progress status  shown in the task management screen and as a percentage progress indicator on the page initiating the task.

Supporting services

In addition to the above, there are additional services such as the database, PDF generators, antivirus systems, web server etc., which play a crucial role in task processing efficiency.

Worker Threads

Each client instance has a set number of worker threads, allowing for simultaneous task processing. Priority is given to immediate front-end user requests, while queued tasks are allocated a maximum number of threads based on availability.