ATutor is a mature learning management system, and the way it behaves under load is distinctive. Course content, SCORM packages, forum threads, and uploaded assignment files accumulate quickly, and a single busy enrollment period can push an account that looked idle for months straight into resource exhaustion. On Hostiso's Managed Cloud Shared Hosting, your account runs inside a CloudLinux LVE (Lightweight Virtual Environment) with hard ceilings on CPU, physical memory, concurrent entry processes, I/O throughput, and inode count. When ATutor stalls, returns 508 errors, or intermittently throws blank pages, the cause is usually one of those ceilings rather than a defect in the application. The practical work is identifying which limit you are striking and tuning what you legitimately control, because many ATutor slowdowns are fixable without a larger plan at all.
Reading which limit you are actually hitting
Before changing anything, confirm the bottleneck with real numbers. In cPanel Jupiter, open Metrics > Resource Usage and click "Details." CloudLinux records every time your account faults against a limit: CPU (reported as a percentage of your allocated cores), physical memory (PMEM), entry processes (EP, the number of simultaneous PHP requests being served), I/O (disk throughput in KB/s), IOPS (operations per second), and process count (NPROC). A graph that repeatedly touches 100% on CPU or PMEM, or that shows "faults" in the EP column, tells you exactly where ATutor is choking. In DirectAdmin Evolution the same data appears under System Info & Files > Resource Usage (LVE). Read the faults column carefully: a few occasional faults during a backup are harmless, but sustained faults during normal browsing mean learners are already being throttled or served 508 "Resource Limit Reached" pages.
Inodes are a separate, quieter limit. An inode is one filesystem object: a file or a directory. ATutor installations balloon in inode terms because every uploaded assignment, every SCORM extraction, every cached thumbnail, and every session file counts as one. Check cPanel > Statistics (left sidebar) for the File Usage figure, or in DirectAdmin the inode count appears on the main dashboard. An account can sit at 10% disk usage yet be at 100% of its inode allowance, at which point ATutor cannot write new sessions or save uploads and begins failing silently. Pair the inode count with a look inside your content/ and session directories using File Manager to see where the objects are concentrated.
Finally, confirm the PHP configuration ATutor is actually running under. In cPanel open MultiPHP Manager to verify the PHP version assigned to the domain (ATutor runs comfortably on PHP 7.4 and modern 8.x branches depending on your release), then open Select PHP Version > Options to see memory_limit, max_execution_time, and max_input_vars. DirectAdmin exposes the same through PHP Selector. Mismatched values here are a frequent, invisible cause of mid-import failures.
Tuning PHP memory, execution time, and workers you control
Most ATutor resource complaints trace back to a handful of PHP directives that you can set per-account without any server-level access. The cleanest place to apply them on LiteSpeed is a .user.ini file in your document root (for example /home/username/public_html/.user.ini), which the PHP Selector also writes to when you edit values in the UI. A sane starting profile for an active ATutor site looks like this:
; .user.ini in the ATutor document root
memory_limit = 256M
max_execution_time = 120
max_input_time = 120
max_input_vars = 3000
upload_max_filesize = 128M
post_max_size = 130MThe reasoning matters more than the numbers. ATutor's SCORM import and course content pages assemble large arrays, and a 128M memory_limit is often where mid-import white screens originate; raising it to 256M resolves the fault without touching anything global. The max_input_vars value protects large quiz-bank and gradebook form submissions, which silently truncate when the default 1000 is exceeded. Keep upload_max_filesize and post_max_size aligned, with the post value slightly higher so multipart form overhead fits. LiteSpeed reads .user.ini changes within a short window; if a value does not apply, give it a few minutes or recycle PHP by touching a file in the root.
Understand what you cannot change directly. The number of concurrent PHP workers is governed by your LVE entry-process limit, not by a PHP-FPM pool you can edit, because editing /etc/ pool files or running systemctl is outside an unprivileged account. If Resource Usage shows EP faults, the fix is to reduce how many simultaneous long-running requests ATutor generates rather than to raise a number. Disable or lengthen the interval of any heavy cron-driven tasks, avoid letting search engine crawlers hammer dynamic course pages, and keep max_execution_time modest so a stuck request frees its worker slot instead of occupying it for minutes. A single runaway report-generation page held open across many tabs can consume your entire EP allowance.
Database queries, I/O, and inode pressure
ATutor's schema is relational and query-heavy, and on a shared database server a missing index or a bloated table turns ordinary browsing into a CPU and I/O problem. Open phpMyAdmin from cPanel or DirectAdmin, select your ATutor database, and sort the table list by size. The usual offenders are the tracking, logging, and forum tables that grow without bound. Run the built-in optimizer by selecting bloated tables and choosing Operations > Optimize table, which reclaims space and rebuilds indexes within your own database — this is fully within account scope and does not require any SET GLOBAL or my.cnf changes, which you cannot perform anyway. For diagnosis, use the SQL tab to run EXPLAIN on a slow query pulled from the ATutor course-listing page; a query showing "Using filesystem; Using temporary" against a large table confirms a sort spilling to disk, which is what spikes your IOPS graph.
Session and cache files are the hidden inode drain. ATutor writes PHP session files and may accumulate stale content extractions under content/. Use File Manager to inspect the directories, and prune abandoned SCORM extraction folders and orphaned temporary uploads that no longer map to active courses. If your session files pile up in the account, confirm a reasonable session.gc_maxlifetime (1440 seconds is typical) in .user.ini so old sessions are collected rather than hoarded. Reducing inode count both clears the ceiling and speeds up every backup and filesystem scan your account runs.
On the delivery side, let LiteSpeed absorb static load so PHP workers stay free for genuine application work. Add caching and compression headers for ATutor's static assets in /home/username/public_html/.htaccess:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>Serving themes, icons, and uploaded media from browser cache cuts repeat requests dramatically, which directly lowers EP, CPU, and I/O faults during busy class hours. The same discipline applies to moving an installation: when inode or storage pressure forces a relocation, plan the file and database steps carefully, much as described in this walkthrough on migrating an LMS between accounts and domains.
Confirming you have genuinely outgrown shared hosting
Upgrade when the data, not a hunch, points there. After you have raised memory_limit, optimized and indexed the database, pruned inodes, and offloaded static assets, revisit Resource Usage over a representative week. If CPU or PMEM still pin at 100% during ordinary concurrent use, or EP faults persist despite reduced request duration, your ATutor site's real working set exceeds what an LVE slice can provide. Sustained I/O saturation from a large, well-indexed database is another honest signal, because shared disk throughput is capped by design and no account-level tuning raises it. At that point a Cloud VPS gives you dedicated cores, larger memory, configurable PHP-FPM pools, and your own database tuning — the controls that are deliberately out of reach on shared hosting. Scaling after exhausting the account-level fixes means you move for capacity, not to paper over a misconfiguration that would follow you to the new server anyway.