Speed Up for Moodle

Hooks into \core\hook\after_config (Moodle 4.5+) and the legacy tool_speedup_after_config() callback on 4.4. The request start comes from $_SERVER['REQUEST_TIME_FLOAT']; an optional X-Request-Start header adds queue time before PHP.

At shutdown it reads counters Moodle already keeps: $DB->perf_get_reads(), perf_get_writes() and perf_get_queries_time(), the session lock wait and hold times Moodle keeps in $PERF->sessionlock, memory_get_peak_usage(), getrusage() CPU time and http_response_code(). No extra queries are made.

Speed Up's own admin pages and Quick Check's test requests (header X-Speedup-Probe) are not recorded.

Uses the Excimer PHP extension (Wikimedia): new ExcimerProfiler() with EXCIMER_REAL and a 10 ms period. Excimer interrupts PHP on a timer and records the stack, so cost scales with time, not with the number of function calls, unlike tracing profilers.

Stacks are compacted to file paths relative to the Moodle code plus class::function names, never line numbers, arguments or values. Long requests keep every Nth sample with weight N (cap 3,000 samples, depth 120), so the whole request is covered.

Profiling is skipped when the 1-minute load per CPU is above the configured limit (cgroup cpu.max quotas are respected in containers).

The shutdown callback only builds the record. It then calls register_shutdown_function() during shutdown, which PHP runs after Moodle's own shutdown manager has closed the session. On PHP-FPM, fastcgi_finish_request() sends the response first.

Lines are appended to one of 16 shard files per web server in $CFG->tempdir/tool_speedup/buffer using fopen('a') + flock(LOCK_EX|LOCK_NB). If the lock is busy it tries one neighbour shard, then drops the record rather than wait. fstat() on every write caps each file at 8 MB.

Circuit breaker: if a write takes over 50 ms (for example a stalled NFS share), a marker in $CFG->localcachedir pauses recording on that server for 5 minutes. Single-server sites can set $CFG->tool_speedup_bufferdir to local disk.

buf-*.jsonl files are renamed to proc-*; files renamed in the previous run are read, aggregated in memory and written in one delegated transaction (a new transaction every 50,000 records). Files are deleted only after commit, so a database error never loses or double counts data.

Existing rows are preloaded with one SELECT … WHERE period IN (…) per table, new rows go in with insert_records(), and each existing row is updated once per run, so query counts depend on distinct pages, not files or web servers.

A directory map built from core_component::get_plugin_types() and plugin lists maps each file to its component (longest prefix, Moodle 5.1 public/ aware). Walking from the innermost frame outwards, the owner is the nearest non-core frame; cache stores, cache locks and log stores are transparent and charge their caller.

The innermost frame classifies the time as database, external call (curl), cache, file, session or PHP code. Each plugin also records its entry point as "caller → function", which is what a developer needs to find the code.

Every page row keeps a histogram with fixed bucket bounds from 50 ms to 34 s. Histograms merge by simple addition, so p50 and p95 can be computed for any period and any group of pages without storing individual requests.

One site-wide row per hour holds totals and the site histogram, so totals and trends read about 840 rows for 35 days. Page rows older than two days are rolled up to one row per page per day.

Impact = time attributable to the cause per request × requests per day, expressed in user-seconds per day. For a plugin it is its owned time per profiled request × total requests; for a page, waiting above a healthy baseline × that page's traffic.

Rules have minimum sample sizes and only fire when the evidence is strong enough (for example 200 profiled requests before a plugin cost is "strongly supported").

An hourly analyser runs rules for plugin cost, external calls, slow pages, heavy queries, server errors, memory, session lock waits, start-up time, PHP-FPM queueing, task failures and backlogs, data loss and software support.

Findings are stored by rule and scope. They update while the problem continues, resolve automatically when it stops, reopen if it comes back, and stay hidden if an admin marks them done. Plugins that are uninstalled disappear at once.

Every hook is wrapped in try/catch (\Throwable) and silent. Recording stops if the buffer has not been processed for two hours (cron stopped), pauses for 15 minutes if the buffer passes its limit (100 MB by default), and the oldest data is dropped first.

Admin pages read cached results keyed by the last processing time and the plugin list hash, so large statistics tables are not re-read on every view. Quick Check has a 60 s overall budget and a 20 s cap on its HTTP test.

A/B test on Moodle 5.3, 800 requests each way: median +1.85 ms (1.3%), mean +0.3%.

100 single-row reads; 20 write-and-commit transactions on Speed Up's own probe table; a 4 KB write with fsync, read and delete in dataroot, tempdir, cachedir and localcachedir (file system type from /proc/mounts, network shares flagged); a set/get on the application cache definition; and the login page fetched anonymously, following redirects manually with Moodle's cURL security rules applied first.

It holds a lock so only one run happens at a time, and releases the admin's session so other tabs keep working.

Sources: php.net/releases/index.php?json=1&version=X.Y (security-tagged releases) and endoflife.date/api/{product}.json for PHP, Moodle and your database. Each source is stored with its own timestamp; a failed download keeps the last good data until it is 8 days old.

The PHP that serves web pages is recorded separately from command-line PHP. Ubuntu, Debian and Red Hat builds receive fixes without changing the version number, so for those Speed Up asks you to confirm updates instead of declaring the site vulnerable.

Implements tool_speedup_performance_checks() (recorder, OPcache, cache stores, sessions, production settings, log table size) and tool_speedup_security_checks() (software support) with the Check API. Log size uses database statistics (pg_class.reltuples, information_schema) instead of COUNT(*).

Pages are recorded as scripts (plus a web service function name, checked against installed functions). Parameter values, cookies and form data are never read. Users fall into two groups, guest and signed-in, so no record can point to one person. The Privacy API provider declares that no personal data is stored.