Claroline is a PHP-based learning management system that behaves very differently from a brochure website. Each active student session triggers document reads, forum queries, quiz submissions, and SCORM package processing, so a course platform that felt instant with ten users can crawl the moment a class of two hundred logs in for a timed exam. On Managed Cloud Shared Hosting the temptation is to assume you have simply outgrown the plan and jump straight to a Cloud VPS. In practice, most Claroline slowdowns trace back to a single measurable constraint that you can identify and often relieve from inside your own hosting account.
The value of finding the exact bottleneck is that CPU exhaustion, memory pressure, PHP worker saturation, inode limits, and database contention all present as "the site is slow," yet each demands a different response. Guessing wrong wastes money and leaves the underlying problem in place. Below we walk through how to read the signals in cPanel Jupiter and DirectAdmin Evolution, what you can genuinely tune as an unprivileged user, and where the honest ceiling of shared hosting sits for a growing LMS.
Reading the resource signals before touching anything
On CloudLinux, every hosting account runs inside its own Lightweight Virtual Environment (LVE), which enforces limits on CPU, physical memory, entry processes, I/O, and I/O operations per second. This is your first and most reliable diagnostic surface. In cPanel Jupiter, open Metrics > Resource Usage and review the "Faults" column. A fault against CPU, PMEM (physical memory), EP (entry processes), or IO means Claroline was actively hitting a ceiling and requests were being queued or killed. In DirectAdmin Evolution the equivalent lives under your user dashboard as the CloudLinux resource usage graphs.
Read the pattern rather than a single spike. Faults that cluster at predictable times, such as the start of a lecture or an assignment deadline, point to concurrency limits (entry processes and CPU) rather than a broken configuration. A steadily climbing memory line that never recovers suggests a leak or an oversized PHP memory allocation multiplied across workers. Sustained IO faults with low CPU usually mean the account is thrashing the disk, often because caching is disabled and Claroline is rebuilding the same data on every request.
Correlate these graphs with your application-level evidence. Claroline writes diagnostic output to your account error log; check File Manager at the document root, typically /home/username/public_html/, for an error_log file, and also review the per-domain logs cPanel exposes under Metrics > Errors. Repeated "Allowed memory size of X bytes exhausted" entries are a memory verdict. "Maximum execution time exceeded" during large SCORM imports or gradebook exports is a time-limit verdict, not a hardware one. Matching an LVE fault to a log line is what separates a real bottleneck from noise.
PHP memory, workers, and time limits you can actually change
Once you know which resource is faulting, the PHP layer is where an unprivileged user has the most control. In cPanel go to Software > Select PHP Version > Options (the PHP Selector), or in DirectAdmin use Account Manager > Select PHP Version. Claroline runs comfortably on PHP 8.1 or 8.2; confirm you are not stranded on an older branch, because newer PHP is measurably faster and lighter per request.
For a document-heavy LMS, the settings that matter most are memory_limit, max_execution_time, post_max_size, and upload_max_filesize. A single Claroline page render rarely needs more than 256M; if you have pushed memory_limit to 1024M to "be safe," you may be the cause of your own PMEM faults, because that ceiling is applied per PHP worker and several concurrent workers can collectively blow past your LVE physical memory allowance. Bring it back to a realistic value and watch whether concurrency improves.
When the PHP Selector UI is limited, set values in a .user.ini file in your document root. This file is read by LiteSpeed and PHP for that directory tree:
; /home/username/public_html/.user.ini
memory_limit = 256M
max_execution_time = 120
max_input_time = 120
post_max_size = 128M
upload_max_filesize = 128M
max_input_vars = 3000The larger upload values only matter for instructors pushing big SCORM archives or video; keep them modest for everyone else. Changes to .user.ini are not instant because PHP caches the file for the duration of user_ini.cache_ttl (commonly 300 seconds), so wait a few minutes before retesting.
The single highest-impact PHP change is enabling OPcache, which caches compiled PHP bytecode and dramatically cuts CPU per request for a large codebase like Claroline. In the PHP Selector, tick the opcache extension, then confirm it is active. If you can adjust opcache.memory_consumption, 128 is a reasonable starting figure. This one setting frequently turns a CPU-faulting account back into a healthy one without any plan change.
Inodes, I/O, and the database layer
Two limits catch LMS operators off guard: inodes and database contention. Every file counts as one inode, and Claroline accumulates them relentlessly through uploaded course documents, per-user work folders, session files, and cache entries. Check your inode count in cPanel under Statistics in the sidebar, or in DirectAdmin under your usage panel. If you are near the account limit, new writes fail silently and Claroline may throw permission or write errors that look like corruption. Use File Manager to clear old temporary and cache directories rather than assuming you need more disk. Session files under the PHP temp directory and stale entries in Claroline's cache paths (under the platform's app/cache or equivalent temp folders depending on your version) are safe to prune when the site is quiet.
I/O faults with normal CPU usually mean uncached repetitive work. Enabling OPcache helps, and if LiteSpeed Cache is available for your account it can serve anonymous, static-like responses without re-running PHP. Do not aggressively cache authenticated LMS pages, since a logged-in student must never see another user's gradebook; scope any caching to public course catalogs and static assets only.
The database is where a growing Claroline most often hits a wall, and it is also where your control is narrowest. You cannot run SET GLOBAL or touch my.cnf. What you can do lives in phpMyAdmin. Open the database, sort tables by size, and look at the forum, tracking, and event logging tables, which balloon over a term. Run Check table and Optimize table on the largest ones to reclaim space and rebuild indexes. Watch the Overhead column, high overhead on a heavily written tracking table directly increases I/O and slows queries. If specific pages hang, the culprit is usually an unindexed query against a huge log table; archiving old tracking data through Claroline's admin tools shrinks the working set that MySQL must scan.
After each change, return to the Resource Usage graph and confirm the corresponding fault count is actually falling. That evidence loop is what justifies staying put. When you have right-sized PHP memory, enabled OPcache, cleared inode pressure, and optimized the heavy tables, yet CPU and entry-process faults still occur during normal class hours, you have reached the genuine ceiling of a shared LVE. At that point a Cloud VPS or a larger plan with a higher CPU allowance and more entry processes is the correct answer, because the constraint is real concurrency demand rather than a fixable misconfiguration. Upgrading with that proof in hand means you buy exactly the headroom your student load requires instead of guessing.