Why Buzzy feels slow before you touch anything

Buzzy is a PHP social/community application that renders feeds, notifications, and user timelines on almost every request. Each of those pages triggers a burst of database queries plus template compilation, and on a shared LiteSpeed server that work is repeated for every single visitor unless something is caching the result. When people report that Buzzy "got slow," the underlying cause is rarely a lack of CPU. It is usually that PHP is recompiling the same scripts thousands of times per minute, that session and query data is being read from disk instead of memory, and that the web server is handing every request straight through to PHP instead of serving a cached copy.

Before changing settings, measure. Open your browser developer tools (Network tab), reload a logged-out Buzzy page, and note the Time to First Byte for the main HTML document. A healthy shared-hosting response is well under 800 ms. If the document itself takes two, three, or more seconds while images and CSS load quickly afterward, the delay is server-side PHP and database work, not bandwidth. Reload the same page a second time: if it is still slow, no caching layer is helping you.

The second diagnostic source is the application's own log. In cPanel File Manager (or DirectAdmin File Manager), navigate to the Buzzy document root, usually /home/USERNAME/public_html, and look for error_log in the root and inside writable folders such as uploads/ and storage/. Repeated PHP warnings, "Allowed memory size exhausted" messages, or slow cron entries reveal exactly which operations are dragging. Also check Metrics » Errors and Metrics » Resource Usage (LVE) in cPanel. CloudLinux enforces per-account limits for CPU, physical memory, and entry processes (EP/PMEM/NPROC faults). If you see faults spiking, PHP is being throttled precisely because it is doing redundant work that caching would eliminate.

Keep those three signals in mind as you apply the fixes below: browser TTFB tells you if the fix worked, the error_log tells you what is failing, and the LVE chart tells you whether you are hitting account limits. Every change here is reversible and done entirely through your hosting account.

PHP Selector, OPcache, and sane runtime limits

The single most effective change for a PHP application is enabling and sizing OPcache. OPcache stores the compiled bytecode of your PHP files in shared memory so the interpreter skips parsing and compiling on every request. In cPanel go to Select PHP Version (the CloudLinux PHP Selector); in DirectAdmin go to PHP Version Selector / Extensions. First confirm Buzzy is running a modern branch such as PHP 8.1 or 8.2, since each release brings measurable execution gains. Under the Extensions tab, tick opcache and, if present, igbinary and redis. Under the Options tab you can adjust runtime values without touching any system file.

Set these values from the Options screen where your host allows it:

opcache.enable = On
opcache.memory_consumption = 128
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = On
opcache.revalidate_freq = 60
memory_limit = 256M
max_execution_time = 60
realpath_cache_size = 4096K
realpath_cache_ttl = 600

Buzzy ships with a large number of PHP files across its framework and modules, so a low max_accelerated_files value causes OPcache to evict scripts constantly, defeating the purpose. Keeping revalidate_freq at 60 means edits you push during maintenance are picked up within a minute rather than requiring a cache flush. If your account does not expose every directive in the Options panel, you can place the same values in a .user.ini file at the Buzzy document root, since LiteSpeed with PHP running as the account user honors per-directory .user.ini:

memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 32M
post_max_size = 40M
realpath_cache_size = 4096K

The upload_max_filesize and post_max_size values matter for Buzzy because failed or oversized media uploads generate retries and error-log noise that look like performance problems. After saving, load a page, then check OPcache status through your host's PHP information page if available. Watch the browser TTFB drop on the second load once bytecode caching is active.

Redis object caching and where Buzzy actually uses it

OPcache accelerates code; it does nothing for repeated database queries. That is Redis's job. Many shared plans on CloudLinux offer a per-user Redis instance. Confirm the redis PHP extension is enabled in PHP Selector, then look for a Redis tool in cPanel or ask whether a socket or a local port is provisioned for your account. Buzzy's caching layer is configured in its environment or configuration file rather than a control-panel screen, so open the Buzzy config through File Manager.

If your Buzzy build is Laravel-based, edit the .env file in the document root and switch the cache and session drivers to Redis:

CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_PASSWORD=null
REDIS_CACHE_DB=1

Some managed setups expose Redis over a UNIX socket instead of a TCP port; in that case set REDIS_HOST to the socket path your host provides and leave the port blank. Moving sessions into Redis is especially impactful for Buzzy because logged-in social activity writes session data constantly, and file-based sessions turn that into thousands of small disk operations. After editing .env, the application must reload its configuration cache. Buzzy admin panels built on Laravel usually include a Clear Cache or Settings » System » Cache action in the AdminCP; use it so the new driver takes effect. Then reload a busy timeline page and re-check the error_log: a misconfigured Redis endpoint throws "Connection refused" immediately, which tells you the host or socket value is wrong rather than the concept.

If Redis is not offered on your plan, keep Buzzy on its file cache but make sure the cache directory is writable and periodically pruned. Bloated, stale cache folders under storage/framework/cache or a similar path can grow to hundreds of thousands of tiny files that slow every write. Deleting the contents of that folder (not the folder itself) through File Manager is a safe reset.

LiteSpeed full-page caching and .htaccess delivery rules

The layers above shorten how long PHP takes; LiteSpeed can skip PHP entirely for anonymous visitors by serving a cached HTML copy. Because Buzzy has no official LiteSpeed Cache plugin the way WordPress does, you drive the cache with .htaccess rules at the document root. Cache only guest pages, and never cache authenticated sessions, admin routes, or POST requests, or logged-in users will see each other's content.

<IfModule LiteSpeed>
CacheLookup on
RewriteEngine On
# Do not cache logged-in users, admin, or dynamic actions
RewriteCond %{REQUEST_METHOD} POST [OR]
RewriteCond %{REQUEST_URI} ^/(admin|login|logout|register|api) [OR]
RewriteCond %{HTTP_COOKIE} (buzzy_session|laravel_session|logged_in) [NC]
RewriteRule .* - [E=Cache-Control:no-cache]
# Cache guest GET pages for 5 minutes
RewriteCond %{REQUEST_METHOD} GET
RewriteRule .* - [E=Cache-Control:max-age=300]
</IfModule>

Verify the session cookie name Buzzy actually sets by inspecting the Application/Storage tab in browser dev tools, and match it in the rule above. A caching rule that misses the real cookie name is the most common reason logged-in and guest views leak into one another. Pair this with long-lived browser caching for static assets so images, CSS, and JavaScript are not re-fetched on every navigation:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/webp "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>

Finally, reduce database strain from inside Buzzy itself. In the AdminCP, look under Settings » General/System for options to disable debug mode in production, limit the number of feed items loaded per request, enable image thumbnails/lazy loading, and turn off analytics or logging features you do not use. Debug mode alone can double response times because it writes verbose traces on every page. When you need to safely apply these changes without risking downtime, take a snapshot first as covered in our guide on safe upgrades, backups, and staging on shared hosting. Re-run the browser TTFB test after each layer: OPcache, then Redis, then LiteSpeed. You should see the biggest jump appear on the second load of any page, which confirms caching is finally doing the repeated work so PHP does not have to.