Using Moodle Fair Allocation for Project Day Planning: Scale, Performance, and Configuration

ByPriya Nair

Will the Fair Allocation plugin handle 600 students and 40 projects?

Short answer: yes, almost certainly. The plugin — mod_ratingallocate, known in German Moodle installations as “Gerechte Verteilung” — has a documented use case of 868 participants distributed across 30 choices with no problems reported. A school running 600 students across 30 to 40 projects falls comfortably within that range.

The worry is understandable. At that scale the algorithm isn’t instant, and the fear of a web-request timeout crashing the whole thing is real. That risk largely went away when newer plugin versions moved the distribution step to a background task instead of running it synchronously inside an HTTP request. More on that in a moment.

What the algorithm actually does

Fair Allocation solves a minimum-cost flow problem. Each student’s rankings become edge costs, and the algorithm — a modified Edmonds-Karp implementation using Bellman-Ford for path-finding — searches for the assignment that minimises total “unhappiness” across all students at once. Nobody gets their first choice at the expense of everyone else being stuck with last pick.

Worst-case complexity is O(m²n²), where m and n are edges and nodes in the flow graph. The developers benchmark 500 users to 21 choices at around 11 seconds on a typical server. Your scenario (600 users, up to 40 choices) is somewhat larger, so expect a bit more time — but we’re talking tens of seconds, not minutes, unless the host is seriously underpowered.

Why older installations sometimes crashed

The server collapse some teachers remember from earlier shared Moodle deployments almost certainly happened because older plugin versions triggered the algorithm synchronously during an HTTP request. PHP enforces a maximum execution time — often 30 or 60 seconds — and the web server kills the process if it runs over. With hundreds of students, that was a genuine risk on tight server configurations.

Newer releases of mod_ratingallocate run the allocation as a Moodle scheduled task or adhoc task: it executes via cron, outside the web request lifecycle, so PHP’s HTTP timeout doesn’t apply. If your Schule@BW instance is on a recent Moodle 4.x build, this should already be the default. One thing worth confirming with your admin: that the Moodle cron job actually fires regularly. If cron is broken or running infrequently, the allocation simply won’t start after the voting period ends, and you’ll be staring at a “pending” status wondering what happened.

Choosing a voting strategy

The plugin offers six strategies. For project days, two tend to work best.

  • Accept-Reject — students tick every project they’d be happy attending. Simple to explain, works well when projects have very different themes and some students would genuinely hate certain ones.
  • Ranking — students order their top choices by preference. Gives the algorithm richer data and usually produces tighter satisfaction scores, but takes students slightly longer to complete.

Avoid Likert-scale or point-distribution strategies for a broad school audience. They need more explanation and students often game them by rating everything identically, which leaves the algorithm with nothing useful to work with.

Setting capacity limits correctly

Each project gets a minimum and maximum participant count. Set the maximum based on room size or facilitator headcount. Set the minimum high enough that the activity actually works — if a project needs at least 10 students to function, set the minimum to 10 so the algorithm doesn’t leave a group of four at an activity that requires a crowd.

One thing that catches first-time users: if the sum of all project maximums is less than the total number of enrolled students, the algorithm can’t allocate everyone and will flag failures. With 600 students and 35 projects, you need an average maximum of at least 18 per project — usually fine in practice, but worth checking before you open voting. Add the numbers up.

How much manual work to expect afterward

With a well-configured activity and near-complete participation, manual post-allocation work is usually modest. Mainly the students who skipped the voting period entirely, plus any edge cases where project constraints couldn’t be satisfied. Whether that’s 10 students or 50 depends almost entirely on the participation rate and how tight the capacity settings are.

Build in a buffer. A voting deadline a full week before the project days leaves time to sort out stragglers without a last-minute scramble. After allocation, the plugin can automatically create Moodle groups from the results — a nice bonus if you want to use those groups for announcements or separate course spaces.

Practical checklist for Schule@BW

  • Confirm your Moodle instance is running a recent release of mod_ratingallocate (the cron-based allocation is in newer versions).
  • Ask your admin whether the Moodle cron job runs at least every few minutes.
  • Set the voting deadline at least a week before project days.
  • Verify that the sum of all project capacity maximums equals or exceeds the number of enrolled students.
  • If this is your first time using the plugin on this instance, run a small dry test with a single class before the full 600-student rollout.

Sources


Similar Posts