How to Measure Moodle Performance in 2026: From Quick Checks to Load Testing
Long before teachers and students notice sluggish pages, performance problems show up as high query counts, slow cron runs, or cache misses. A disciplined measurement framework helps you spot those signals early and answer the question every administrator eventually faces: Is my platform fast enough, or am I one quiz event away from disaster?
Use the four tiers below to build a monitoring strategy that scales from quick spot checks to enterprise-grade observability. MooDIY Cloud runs this playbook for every managed site; here's how you can adopt it too.
1. What Good Performance Looks Like
Core Performance Targets
| Metric | Target | Warning | Red flag | Impact |
|---|---|---|---|---|
| Page generation time | <300 ms | >600 ms | >2 seconds | User disengagement/abandonment |
| DB queries per page | 20-200 | >500 | >1,000 | Database overload |
| Cache hit ratio | >95% | <90% | <85% | Expensive DB reads |
| CPU iowait | <10% | >20% | >30% | Disk bottleneck |
| Free memory | >20% | <20% | Swapping | OOM kills |
| SSD disk latency | <5 ms | 5-10 ms | >10 ms | File upload delays |
| Cron completion | Within interval | Near limit | Backlog growing | Late notifications |
The Cost of Guessing
Many administrators operate without baseline metrics, reacting only when users complain. By then, you're firefighting instead of preventing. A single exam-day outage can result in lost instructional time, emergency vendor calls at premium rates, reputational damage, and technical debt that compounds over semesters.
Measurement prevents surprises. The question isn't whether to monitor -- it's how deeply to invest.
Four-Level Monitoring Overview
| Lvl | Name | Setup | Best for | Cost |
|---|---|---|---|---|
| 1 | Quick snapshots | 1-2 hrs | <500 users, solo admin | Time only |
| 2 | Built-in instrumentation | 30 min | 500-2,000 users | Free |
| 3 | Synthetic load testing | 4-8 hrs | High-stakes exams, 300+ concurrent | Free + staging ~$50-200/mo |
| 4 | Continuous observability | 8-16 hrs | SLA commitments, 24/7 operations | $50-500/mo tools |
2. Level 1 -- Spot Checks
Investment: 1-2 hours setup, 15 minutes per check.
Start here if you're a solo administrator, running a small site (under 500 users), or just establishing a baseline. These tools require minimal setup and deliver fast, repeatable snapshots.
Benchmark Report Plugin
Install the Report Benchmark plugin to capture a repeatable baseline of CPU throughput, file I/O speed, database query performance, and page render time. Run it before and after configuration changes to quantify the impact. A well-tuned server (4 vCPUs, 8 GB RAM, SSD) should complete the benchmark in under 60 seconds. If your benchmark takes three minutes, your infrastructure is already under strain.
Budget: Time only. Suitable for sites under 500 users with in-house technical skills.
External Page Graders
Use GTmetrix, PageSpeed Insights, or WebPageTest to reveal front-end bottlenecks. These tools measure Time to First Byte (TTFB), asset waterfall, and unused JavaScript that bloats page weight. A Moodle page with 2 MB of uncompressed JavaScript and no caching headers will perform poorly even on a fast server.
Budget: Free. 30 minutes monthly. Best for quick wins like enabling gzip compression or deferring non-critical JavaScript.
When to Graduate to Level Two
If you're checking more than once weekly, spending more than 30 minutes per check, or finding issues you can't diagnose with snapshots, you need instrumentation built into the platform.
3. Level 2 -- Built-In Diagnostics
Investment: 30 minutes setup, always-on visibility.
Once you outgrow spot checks, enable Moodle's developer tools for real-time visibility into every page without external tooling. Best for sites with 500-2,000 users or administrators who need to diagnose slow pages during normal browsing.
Performance Info Footer
Enable developer debugging so every page footer shows generation time, memory consumption, query count, and included files. This turns every admin click into a diagnostic opportunity -- you'll immediately notice when a single page performs 800 queries or consumes 256 MB of memory.
How to enable: Site administration > Development > Debugging
Set debug level to DEVELOPER and enable Performance info. Only enable on staging environments or restrict to admin roles.
Budget: Free. Takes 5 minutes to enable. Does not capture patterns over time -- for that, move to Level 4.
Performance Overview Report
Site administration > Reports > Performance
Overview of Moodle's built-in health checks. It flags missing caches, large log retention, or disabled PHP accelerators. In representative Moodle tuning work, disabled OPcache is often a multi-fold page-generation penalty, so treat that warning as an immediate action item rather than a cosmetic recommendation.
Budget: Free. 10 minutes monthly.
Task Log Monitoring
Site administration > Server > Tasks > Task log
Monitor long-running scheduled tasks. If your backup task takes six hours or your search index rebuild times out, you'll see it here. A growing backlog is an early warning sign of insufficient worker capacity -- tasks are queuing faster than they can be executed.
Budget: Free. 15 minutes weekly. Critical for sites with heavy automation: automated enrollments, certificate generation, and complex grading.
When to Graduate to Level Three
If you're managing exam schedules, supporting over 2,000 concurrent users, or need to prove capacity before high-stakes assessments, you need controlled load testing -- not just monitoring what happens organically.
4. Level 3 -- Load Testing Before It Matters
Investment: 4-8 hours setup, 2-4 hours per test cycle.
Load testing simulates peak usage before it happens in production. Essential for exam windows with 500 simultaneous quiz attempts, enrollment surges, or semester starts. You're buying certainty -- the confidence that your platform will handle the load.
Generate Sample Data at Scale
Site administration > Development > Make test courses
Build users, courses, and activities at a realistic scale. Don't test with ten users and extrapolate -- performance degrades non-linearly. A platform that handles 50 users comfortably may collapse at 200 due to database locking, connection pool exhaustion, or cache saturation. Mirror production workload: if your real users create forum posts, upload assignments, and take quizzes, your test data should match.
Budget: Free in-house, but requires a staging environment (~$50-200/month for a production clone). 2-3 hours setup.
Create and Run JMeter Test Plans
Moodle's built-in Make JMeter test plan generates a ready-to-run .jmx file that simulates logins, course navigation, and quiz attempts. JMeter replays these actions with configurable concurrency and ramp-up time. This is the industry-standard approach for validating capacity.
What to test: Model your peak scenarios. For 300-seat exams, configure JMeter for 300 concurrent users over a 15-minute window. Track:
- Response time percentiles (p50, p95, p99 -- p95 tells you how bad the experience gets for your slowest users)
- Error rates (any 500 errors or timeouts are failures)
- Throughput (requests per second your platform sustains)
While JMeter runs, watch server dashboards: CPU at 100% = capacity-bound; high iowait = disk-bound; memory swapping = more RAM needed.
Budget: JMeter is free. Skilled labor: 4-8 hours per cycle. External consultants: $150-300/hour ($600-2,400 one-time validation). Cheap insurance for high-stakes assessments.
Iterate and Document
Apply tuning (enable Redis caching, add database indexes, increase PHP-FPM workers), rerun the test, and document improvements. This creates a performance optimization record -- if a plugin update later degrades performance, you have a baseline to compare against. After 3-4 cycles, you will have a well-tuned platform with documented capacity limits.
Budget: 2-4 hours per tuning cycle.
When to Graduate to Level Four
If you're managing multiple sites, need SLA commitments, or want alerting before issues surface to users, you need continuous observability -- not just periodic testing.
5. Level Four -- Continuous Observability
Investment: $50-500/month for tools + 8-16 hours setup.
Enterprise-grade observability monitors all layers -- application, database, and infrastructure -- continuously, with alerting that triggers before users complain. Essential for organizations with SLA commitments, 24/7 operations, or platforms where downtime costs thousands per hour.
Database Layer Monitoring
Enable MySQL/MariaDB slow query logs to capture queries over 1 second. Run pt-query-digest from Percona Toolkit weekly to identify the worst offenders -- poorly indexed queries, full table scans, and missing JOINs. Many performance issues stem from a single unoptimized query that runs thousands of times per hour.
Use mysqltuner for actionable advice on buffer pool sizing, query cache configuration, and index effectiveness.
Budget: Tools are free. DB expertise: $100-200/hour consultant if needed. Managed DB services (RDS, Azure): $50-200/month.
System Monitoring with Prometheus and Grafana
Deploy Prometheus (metrics every 15 seconds) and Grafana (trend visualization) to capture patterns that spot checks miss: gradual memory leaks, disk space depletion, CPU spikes correlated with cron runs, and network saturation during backups.
Budget: Self-hosted = free (8-12 hrs setup, 2-4 hrs/month maintenance). Managed (Datadog, CloudWatch): $50-200/month small, $500+/month multi-site.
Application Performance Monitoring (APM)
Tools like New Relic, Elastic APM, or Datadog APM trace PHP execution, external API calls, and Moodlelib bottlenecks. They answer: "Which function consumed 80% of page generation time?" or "Why did this cron task time out?" APM is invaluable when specific scripts or plugins misbehave under load.
Budget: New Relic from $99/month. Elastic APM is free self-hosted (8-10 hrs setup) or $95+/month on Elastic Cloud. Datadog from $15/host/month.
Alerting Thresholds
| Metric | Warning | Critical | Action |
|---|---|---|---|
| PHP-FPM queue depth | >20 requests | >50 requests | Scale workers or add a web node |
| Response time | >600 ms | >2 seconds | Investigate slow queries, check resources |
| CPU usage | >70% sustained | >85% sustained | Add capacity |
| DB connections | >70% of max | >90% of max | Increase max_connections or find leaks |
| Cache hit ratio | <95% | <85% | Investigate cache misses, check Redis |
| Disk space free | <20% | <10% | Archive old data, expand storage |
| DB replication lag | >30 seconds | >60 seconds | Standby falling behind -- investigate I/O |
Good alerts are actionable and tuned to avoid noise. A poorly configured system that cries wolf trains administrators to ignore warnings.
Budget: PagerDuty, Opsgenie, or VictorOps -- $20-50/user/month for 24/7 ops. Email alerts from Grafana or CloudWatch are free and sufficient for smaller teams.
Why Expert Monitoring Matters -- Even With the Right Tools
Tools generate data, but expertise turns data into action.
A slow query log doesn't fix itself. An alert that disk space is low doesn't provision storage. A JMeter test showing 3-second response times doesn't reveal whether the bottleneck is PHP workers, database connections, or cache misses. You need the skill to interpret signals and the time to act on them.
How MooDIY Cloud Handles Performance Measurement
MooDIY Cloud applies this measurement playbook across managed hosting engagements -- with the exact tooling and response commitments depending on the selected plan and assessment needs.
Level 1-2: Baseline and Instrumentation
- Automated benchmark runs on onboarding to establish your baseline and validate infrastructure
- Redis-backed cache telemetry tracking hit ratios in real time, with alerts if performance drops below 95%
- Cron monitoring -- if the backlog grows, we scale workers proactively
Level 3: Pre-Deployment Load Testing (On Request)
- JMeter test plans against your staging environment before high-stakes assessments
- Capacity validated at 20% above your concurrency target
- Load test report with response time percentiles, error rates, and capacity recommendations before go-live
Level 4: Enterprise Observability
- Prometheus + Grafana-style dashboards across the infrastructure layers included in your plan
- Database monitoring with slow query analysis, index checks, and automated tuning recommendations
- APM for PHP execution, plugin performance, and external API latency where the plan scope requires it
- Alerting and escalation for managed environments -- tighter SLA commitments are handled in enterprise agreements
- Critical incident response targets documented in the selected support plan
The Real Difference: Proactive Action, Not Just Data
We don't just collect metrics - we act on them. When our monitoring detects:
- Growing database query times, we analyze slow query logs, add indexes, and validate the fix
- Rising memory usage, we investigate for leaks, tune PHP-FPM, or scale infrastructure
- Increasing cron duration, we profile tasks, parallelize workloads, or provision dedicated workers
You get performance reports quarterly showing trends, optimizations applied, and capacity headroom. No surprises, no firefighting - just disciplined measurement and expert response.
This frees your administrators to focus on pedagogy while our engineers watch the graphs and keep the platform fast.
Related reading: Dive deeper into Moodle performance optimizations, understand high-concurrency quiz planning for high-traffic periods, or learn why AWS hosting gets expensive fast.