Moodle: how to plan online exams for many students at once

Describe the assessment before choosing VPS capacity

Record participant count, duration, access window and expected clustering of activity. Distinguish one class starting in the same minute from several staggered classes. Include question types, images, files, plugins and authentication integrations: two exams with the same student count can create different server workloads.

Moodle documentation distinguishes registered accounts, logged-in users and requests currently being processed. One student may keep reading without making a new request; another may change pages and save answers repeatedly. A capacity promise based only on accounts or simultaneous students therefore leaves out the behavior that needs to be measured.

Define timing and expected attempt behavior

Review opening and closing times, time limits, allowed attempts and relevant quiz options. Check how the installed version handles time expiry and the configured situations. Do not discover those rules during the exam. Also consider authorized accommodations for participants who need different conditions.

Complete an attempt as a test student and check the displayed schedule and remaining time. The team should know what students see when they arrive early, resume an attempt or finish. Educational and assessment rules are defined in Moodle by the institution; changing VPS resources does not define those policies.

Rehearse saving and submission, not just login

Logging in demonstrates only a small part of the experience. The test should open the quiz, load content, answer questions, save, change pages and finish according to the configured activity. Check the attempt record and its status in the appropriate monitoring view. A fast home page does not prove that final submission will work at peak load.

Include a client-side network interruption in a controlled environment and verify the supported resume procedure. Do not promise loss-free recovery from every connection failure. Explain to students and staff how to identify a recorded attempt and report a discrepancy with enough information, without exposing answers or personal data in public channels.

Observe the layers involved in each request

PHP, the database, disk and network contribute in different ways. Busy processes may be waiting for a query or file rather than continuously using CPU. Observe memory, storage activity, connections, request duration and errors during the test. One indicator alone does not explain the whole experience.

Check the PHP, database and extension requirements of the Moodle version and plugins in use. A larger plan does not fix an incompatible extension. If a query or external service is slow, investigate that path. Record the environment and tested version so that results can be tied to the configuration intended for the exam.

Cache and sessions require their own configuration

Moodle has caching mechanisms and authenticated workflows that must follow its documentation. Do not apply public page caching to an assessment or personal content as a shortcut to speed. Each student must continue to receive their own session, attempt and permissions.

Redis or another service does not automatically improve performance merely by being present on the server. Confirm the purpose, supported component and configuration required by the adopted version. Test independent accounts and verify isolation. Changes to session or cache storage should be rehearsed before the assessment window, with a known recovery path.

Monitor cron and background tasks

Cron is part of Moodle operation and runs scheduled tasks. The documentation recommends regular execution, normally every minute, according to the environment and version. Verify the command, user, effective PHP version and failure monitoring. Do not disable cron indiscriminately to free capacity during the exam.

Also consider the impact of heavy tasks running at the same time. Backups, reports and other routines can compete for resources during the assessment. Schedule the tasks you control and monitor those that must continue. Preserve software functionality rather than removing services without understanding their dependencies.

Build an authorized, representative load test

Use an environment and test accounts you are authorized to operate, with fictitious data and no unintended real messages. Define flows, pacing and acceptance criteria before starting. Establish a baseline and increase load in a controlled way; do not send traffic to services outside the test scope.

As a hypothetical example, an institution with two classes in the same window should simulate the expected concentration of activity at opening and submission, rather than spread visits evenly. The example’s participant count does not establish a recommended plan. Record observed behavior, test duration and anything outside its scope.

1. Create a compatible test copy and confirm that external integrations are controlled.
2. Execute a complete individual attempt and record the initial reference.
3. Reproduce access and actions matching the expected assessment profile.
4. Monitor latency, errors, resources and attempt status.
5. Include the final-submission peak and verify the recorded result.
6. Adjust one hypothesis at a time and repeat the measurement under comparable conditions.

Use acceptance criteria the team can verify

Define what must remain functional and acceptable delays for each important stage. Include the absence of significant errors, correctly recorded attempts and the ability to diagnose issues. A good average can hide delays affecting some participants; also examine the distribution and the slowest cases.

Distinguish laboratory results from operational commitments. A simulation does not cover every student device, network or behavior. Explain its limitations and retain headroom for the observed scenario. Do not turn a small test into a guarantee for a much larger class or an assessment with different components.

Prepare contingency procedures without improvising on the data

Assign a technical owner and an assessment owner, with contact channels and the information needed to reach each. Preserve evidence of problems and avoid version or plugin changes close to the exam. If intervention is necessary, establish timing, environment and impact before carrying it out.

A backup strategy must include the required data and files and be tested in isolation. Restoring an earlier copy in production can remove answers received after that point; this requires analysis and coordination, not an automatic click during the exam. Infrastructure recovery and educational handling of attempts are complementary tasks.

How WordPane helps plan this Moodle environment

WordPane offers Moodle in compatible PHP environments using Apache or Nginx and brings infrastructure operations together in the panel. Metrics and logs help relate server behavior to the assessment period; scheduled tasks help organize compatible routines. Confirm versions and requirements before contracting.

Backup configuration with external storage helps prepare verifiable recovery; destination, cost, scope and restoration must be defined. The platform does not replace course creation, quiz rules or educational administration. Bring the exam profile, plugins, access concentration and test results to the briefing to assess capacity and responsibilities without promising a universal student count.