How to run the tests (moodle 45)¶

Moodle Quiz Load Testing — Setup and Procedure (Moodle 4.5, 2026)¶

This page describes how to set up and run the quiz load tests.
For actual results and infrastructure sizing data, see: Load_test_results_moodle45_2026

Attached to this page:

• Moodle quiz backup (16-question quiz, 8 pages)
• Test users file (CSV, for bulk upload and enrollment)
• JMeter script (jmx)

---

Setting up test data in Moodle¶

1. Create a course for the test (or use an existing one).
2. Restore the quiz backup (.mbz file) into that course.
3. Upload test users via Site administration > Users > Accounts > Upload users.
   • The CSV file contains 5000 users. Edit the course column to match your course shortname.
   • Set "Force password change" to None.
4. Enroll all users in the course (handled by the upload if the CSV includes the course column).

After the test, verify that attempts and answers were recorded correctly in the quiz results.

Resetting between runs: if a test run is interrupted before finishing, attempts remain "in progress".
Users cannot start a new attempt in that state. Reset with:

UPDATE mdl_quiz_attempts SET state='finished' WHERE quiz=<quiz_id>;

---

JMeter script configuration¶

The script requires the JMeter Plugins Manager. Download plugins-manager.jar from
https://jmeter-plugins.org/install/Install/ and place it in lib/ext/ (restart JMeter).

Tested with JMeter 5.6.3 and Moodle 4.5.

Open the .jmx file and adjust:

1. Test Plan — set course_id, quiz_id, and server hostname.
2. CSV Data Set Config — set the path to the users CSV file.
3. Thread Group — set number of threads (VUs) and ramp-up time.
   • Start with 1 thread to confirm the test runs without errors before scaling up.
   • We tested up to 3000 threads with 180 s ramp-up.
4. Synchronizing Timer (before startattempt) — holds all VUs at the exam start point until
   the configured number arrive, then releases them together. This simulates the real-world
   burst when all students click "Start attempt" at the same time. Set the number of simultaneous
   threads to match your VU count.
5. Gaussian Random Timer (after startattempt, σ=30s, offset=5s) — introduces post-start
   dispersion simulating students reading and answering at different rates.

---

Running the tests¶

From the command line (recommended for load tests — GUI mode has overhead):

./jmeter -n -t /path/to/moo4quiz.jmx -l /path/to/output.jtl \
  -Xms8g -Xmx8g -XX:+UseG1GC

JMeter machine sizing: use a dedicated machine. We used 32 GB RAM / 8 CPU.
With a single client we ran up to 2000 VUs reliably. For 3000 VUs we did not observe
client-side errors, but if you do, consider splitting the load across two JMeter instances
or using JMeter's distributed testing mode.

---

Server monitoring during tests¶

Capture server-side metrics during each run to correlate with JMeter results.
A simple shell script running at 10-second intervals collecting the following is sufficient:

• uptime — load average (1, 5, 15 min)
• free -m — RAM and swap used
• ps aux | grep apache — Apache process count
• curl -s 127.0.0.1/fpm-status — PHP-FPM pool status (total, busy, idle workers)
• ss -s or netstat — HTTPS connections (port 443), MySQL TCP connections

Write output as CSV (one line per interval) for easy post-processing.

For the database server, nmon -f -s 5 provides CPU, memory, disk I/O, and network at
5-second granularity.

---

Tips and lessons learned¶

• Repeat each test at least twice. On shared VMware infrastructure, hypervisor contention
  from other VMs introduces variability. Two identical runs let you distinguish real behavior
  from noise.
• The startattempt spike is the critical moment. Everything else in the quiz is easy for
  the server. Focus your analysis on the synchronized exam start — that is where the system
  will fail first.
• mod_cache on the reverse proxy improves static asset delivery (10–35% latency reduction)
  but can worsen the startattempt spike by delivering pre-exam pages faster, clustering VUs
  more tightly at the synchronization point.
• CPU, not RAM, is the bottleneck with PHP-FPM + OPcache. Don't over-provision RAM at the
  expense of CPU cores. See Load_test_results_moodle45_2026 for detailed data.
• InnoDB buffer pool sizing matters. If the working dataset fits in the buffer pool,
  the database server will show near-zero read I/O during the test. Ensure
  innodb_buffer_pool_size is set appropriately (we used 16 GB RAM on the DB server).
• Check OPcache hit rate during tests (opcache_get_status()). With a warm cache,
  hit rate should be above 99%. A cold OPcache at test start will produce artificially
  poor results for the first few requests.