LiteCart is a lightweight PHP and MySQL storefront, which fools people into assuming it will never strain a shared hosting account. In practice, a growing catalog, an aggressive crawler, or a poorly indexed database will push a small plan into throttling long before the store looks "big." The symptoms are familiar: intermittent 508 Resource Limit Reached pages, slow checkout, a spinning admin dashboard, or a storefront that stalls for a few seconds every time a bot sweeps the category pages. The instinct is to buy a bigger plan. The better first step is to identify which single resource is actually saturating, because most LiteCart bottlenecks are fixable from inside an unprivileged account.

On our Managed Cloud Shared Hosting each account runs under CloudLinux, which places every user inside a Lightweight Virtualized Environment (LVE). That means your CPU percentage, physical memory (PMEM), entry processes (EP), number of processes (NPROC), and I/O throughput are all capped per account. When any one of those ceilings is hit, LiteCart requests are queued or killed, and you see a 508 rather than a clean error. The goal of this article is to read those meters correctly, then apply targeted fixes to PHP, LiteScript caching, the database, and inode usage.

Reading the meters: which resource is actually failing

Guessing wastes time. Start with the numbers your control panel already exposes. In cPanel Jupiter, open the Metrics > Resource Usage tool and view the "Current Usage" and "Snapshots" tabs. This is the CloudLinux LVE report, and it tells you precisely which limit was hit in the last 24 hours: CPU, PMEM, EP, NPROC, or IO/IOPS. In DirectAdmin Evolution the equivalent lives under Advanced Features > Resource Usage or the account's Statistics panel. Do not skip this step. A store that throttles on CPU needs a completely different remedy than one throttling on Entry Processes.

Interpret the columns like this. A high CPU fault count usually means expensive PHP execution: uncached page generation, image thumbnailing on the fly, or slow SQL that keeps the PHP worker busy. High EP (Entry Processes) means too many simultaneous requests are entering PHP at once, typically from bots, XML-RPC-style hammering, or a checkout page that never caches. High PMEM points to a PHP memory_limit set too high multiplied across many workers, or a single import script loading a huge dataset. High IO/IOPS indicates disk thrashing, often from a session pile-up, verbose logging, or unoptimized image reads. High inode counts (visible in cPanel under Statistics > File Usage) rarely throttle CPU but will silently break the account once you cross the plan's file-count cap.

Cross-reference with LiteCart's own logs/ directory and the per-directory error_log that PHP writes into your document root. Open these with cPanel File Manager. Repeated PHP fatal errors about exhausted memory, or warnings about maximum execution time, confirm a PHP-side bottleneck rather than a raw hardware ceiling.

Tuning PHP without root: Selector, .user.ini, and OPcache

LiteCart's admin, import routines, and image handling are the heaviest PHP consumers. You can shape all of them through the account-level PHP controls. In cPanel open Software > Select PHP Version (the PHP Selector), or in DirectAdmin use PHP Selector under the account menu. Confirm LiteCart is running on a supported branch such as PHP 8.1 or 8.2; older 7.x builds are slower and less memory efficient for the same workload.

The single most effective CPU fix is OPcache. In the PHP Selector "Extensions" tab, enable opcache, then in the "Options" tab set sensible values. OPcache stores compiled bytecode in memory so LiteCart's PHP files are not recompiled on every hit, which directly lowers CPU fault counts under crawler load.

; Set via PHP Selector Options, or in public_html/.user.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Resist inflating memory_limit to fix a 508. A store throttling on PMEM gets worse when each worker is allowed 1024M, because CloudLinux counts the sum across all active processes. Keep the storefront at a realistic value and only raise limits for the specific admin task that needs it. You can scope this using a second .user.ini placed inside the admin directory rather than the whole account:

; public_html/admin/.user.ini  (only affects the admin panel)
memory_limit = 256M
max_execution_time = 300
max_input_vars = 5000

For catalog or order imports that time out, run them during off-peak hours and keep max_execution_time generous only where the import script lives. This keeps the storefront lean while giving batch jobs room to finish.

LiteSpeed caching and database bottlenecks

If the meters show CPU and EP faults driven by page generation, the fix is to stop generating pages you can serve from cache. Our servers run LiteSpeed Web Server, which honors public cache headers set through .htaccess. LiteCart's checkout, cart, and account pages must never be cached, but static assets and anonymous category pages can be. Add a targeted rule to public_html/.htaccess:

<IfModule LiteSpeed>
  CacheLookup on
</IfModule>

# Long cache for static assets only
<FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|woff2|svg)$">
  <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault "access plus 30 days"
  </IfModule>
  Header set Cache-Control "public, max-age=2592000"
</FilesMatch>

Bot traffic is a frequent, hidden cause of EP exhaustion. LiteCart generates dynamic pages for aggressive crawlers hitting every filter and sort permutation. Trim that load in .htaccess by rate-limiting or blocking the worst offenders and by declining query-string variants you do not need indexed:

RewriteEngine On
# Block a known aggressive crawler by user agent
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|MJ12bot|SemrushBot|DotBot) [NC]
RewriteRule ^ - [F,L]

On the database side, LiteCart's slowdowns are almost always missing indexes and a bloated sessions or logging table, not raw MySQL capacity. Open phpMyAdmin from cPanel or DirectAdmin and inspect the largest tables under the store database. Truncating stale session rows and old cart records recovers I/O and shrinks query times immediately. Check that frequently filtered columns such as product status and category joins are indexed; use the SQL tab to run EXPLAIN on a slow catalog query and confirm it is not doing a full table scan. Add a normal index through the phpMyAdmin Structure tab rather than any server-wide command, since you cannot touch global MySQL configuration on shared hosting. Regularly run Operations > Optimize table on high-churn tables to reclaim space and reduce IOPS.

Inode pressure deserves its own pass. LiteCart's cache and generated thumbnail directories can accumulate tens of thousands of tiny files. In File Manager, review cache/ and any image cache folder, clear obsolete files, and set the store to prune its cache on a schedule. Dropping inode usage keeps the account under its file cap and lightens directory-read I/O at the same time.

When a fix is not enough: the case for a larger plan

After OPcache, LiteSpeed caching, bot filtering, indexed queries, and cleaned sessions, re-check the Resource Usage snapshots over several days. If the store now stays under its limits during normal traffic, the bottleneck was configuration, and you have saved the cost of an upgrade. If the meters still peg CPU or EP at peak with clean, cached, well-indexed code, you have reached a genuine capacity ceiling. That is the honest trigger for a Cloud VPS or a larger plan with a higher CPU allowance and more entry processes, because those limits cannot be lifted from inside an unprivileged account. The principle mirrors what we cover for larger PHP stores in our guide on Sylius performance and caching on shared hosting: exhaust the account-level tuning first, then scale the hardware only for the resource that remains saturated.