Performance & Scale

• Caching: Configure MUC to use Redis for Application and Session caches.
• Database: Use a Master-Slave replication setup. Offload read-heavy operations (reports) to the slave.
• Web Servers: Load balance multiple web servers (Nginx/Apache) behind a proxy (HAProxy/AWS ALB).
• Files: Use an external object store (S3) or a shared high-performance file system (NFS/EFS) for moodledata.
• Cron: Ensure cron runs frequently (every minute) to process background tasks.

MUC is Moodle's unified caching system. It allows administrators to configure different cache stores (File, Session, Redis, Memcached) for different cache definitions (Language strings, Database meta-data, Course contacts) without changing code.

Enable 'Performance info' in Site Administration. This shows DB query counts, RAM usage, and execution time in the footer. For deeper analysis, use XHProf or Tideways to generate a flame graph of function calls.

Moodle supports different session drivers. By default, it uses files. For high availability, use Redis or Memcached to store sessions, allowing users to switch between web servers without logging out.

Avoid N+1 queries (querying inside a loop). Use get_records_sql with IN (...) clauses. Ensure tables have proper indexes on columns used in WHERE and JOIN clauses. Use EXPLAIN to analyze query plans.

A setting that prevents Moodle from caching theme CSS and JS. It is essential for development but must be disabled in production, as it severely degrades performance.

A long-running cron can block other tasks. Moodle's task system allows parallel execution. Offloading heavy tasks (like backups or report generation) to ad-hoc tasks ensures the main cron loop finishes quickly.

Moodle minifies and concatenates JavaScript files into cached bundles. This reduces the number of HTTP requests and file sizes, speeding up page load times for users.

Moodle compiles language strings into a binary format or caches them in memory. This avoids parsing thousands of PHP language files on every request.

Configure PHP's upload_max_filesize and post_max_size. For very large files, use repository plugins (like Google Drive) to link files instead of storing them in Moodle, or configure the web server (Nginx/Apache) to handle large bodies efficiently.

Moodle can be configured with a separate database connection for read operations ($CFG->dboptions['readonly']). This allows distributing the load to a read replica database server.

A heavy operation that clears all MUC stores, theme caches, and JS caches. It causes a temporary performance spike as caches rebuild. Avoid doing this on a live production site during peak hours.

Enable 'Async backups'. This offloads the backup process to an ad-hoc task, preventing the user's browser from timing out and reducing the load on the web server process.

A PHP extension that caches compiled bytecode. It is mandatory for Moodle performance. Ensure opcache.memory_consumption is large enough to hold all Moodle scripts.

The database layer caches table metadata (column names, types) to avoid querying the database schema on every request. This is stored in the MUC.

Optimize PHP execution time. Use efficient code, minimize DB queries, use caching effectively, and ensure the server hardware (CPU/RAM) is adequate.

A web server feature (Apache/Nginx) that allows PHP to delegate file serving to the web server. Moodle supports this ($CFG->xsendfile), significantly improving performance when serving files from moodledata.

Use tools like New Relic, Nagios, or Zabbix. Monitor CPU, RAM, Disk I/O, Database connections, and specific Moodle metrics (cron delay, failed tasks).

Moodle caches the course structure (sections, modules) in the course_modinfo cache. This speeds up the display of course pages. Rebuilding this cache (e.g., after bulk editing) can be expensive.

PHP locks the session file during a request. If a user opens multiple tabs, requests are serialized. Moodle's read-only session support (for some pages) helps, but using Redis for sessions is generally faster and handles locking better.

Text filters (like TeX or Auto-link) can be expensive. Moodle caches the filtered result of text to avoid re-processing it every time the page is viewed.

The gradebook can be slow in large courses. Moodle uses 'Grade history' and aggregation tasks. Ensure 'Grade export' and 'Grade report' settings are optimized, and avoid excessive grade items.

The process of removing whitespace and comments from CSS and JS files. Moodle does this automatically. Ensure your custom plugins use the AMD structure so their JS is also minified.

The mdl_logstore_standard_log table grows rapidly. Configure 'Log retention' settings to delete old logs automatically. Consider using an external log store (Splunk, ELK) for long-term retention.

Moodle uses moodledata/temp for backups, restores, and file processing. Ensure this partition has enough space and high I/O performance.

When syncing thousands of users (e.g., LDAP/Database sync), run the task via CLI, not the web interface. Use the 'Flat file' enrolment for bulk updates if real-time sync is too slow.

Using technologies like Galera Cluster or PostgreSQL clustering to provide high availability and load balancing for the database layer.

Moodle automatically resizes user-uploaded images. However, encourage users to optimize images before upload. Use a CDN to serve static assets and images to reduce load on the Moodle server.

Loading resources (like images or course content) only when they scroll into view. Moodle 4.0+ implements lazy loading for course activities to improve initial page load speed.

FastCGI Process Manager. It is the recommended way to run PHP with Nginx or Apache. It handles high loads better than mod_php by maintaining a pool of worker processes.