Laravel Cache Commands

Laravel recompiles config, routes, and views on every request unless they're cached. On a production instance, this alone can add noticeable latency to every page load. Run:

php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan optimize

Why it matters: config:cache collapses all config files into a single cached file so Laravel doesn't re-read and re-parse .env and config arrays on every request. route:cache does the same for route definitions — especially valuable on an app like 6amMart with a large number of admin, vendor, and API routes. view:cache precompiles Blade templates so they don't need to be compiled on first hit after a deploy.

Caution: If you make config, route, or view changes after this, you must re-run these commands (or php artisan optimize:clear), or you'll be serving stale cached versions.

2. Confirm PHP OPcache Is Enabled

PHP has to compile PHP files into bytecode before executing them. Without OPcache, this compilation happens on every single request — a significant, avoidable cost.

Check your php.ini:

opcache.enable=1

You can confirm it's active by checking phpinfo() output or running:

php -i | grep opcache.enable

Why it matters: With OPcache on, compiled bytecode is cached in shared memory, so repeat requests skip the compilation step entirely. On a busy Laravel app, this is often one of the single biggest performance wins available — and it's usually a five-minute fix if it's missing.

3. Confirm Supervisor Is Running the Queue Worker

6amMart relies on Laravel's queue system for background jobs — order notifications, emails, SMS/OTP sends, and other async tasks. If no queue worker is running, or if jobs are misconfigured to run synchronously, these tasks execute inline during the web request itself, which can visibly stall page loads.

Check:

supervisorctl status

You're looking for your laravel-worker (or similarly named) process showing RUNNING. If it's STOPPED, FATAL, or missing entirely, notifications and emails are likely blocking requests rather than processing in the background.

Fix if needed: Reload and restart the worker via Supervisor:

supervisorctl reread
supervisorctl update
supervisorctl restart laravel-worker:*

4. Enable MySQL Slow Query Log and Add Missing Indexes

This is usually where the biggest wins hide on a multivendor app like 6amMart, where orders, products, and stores tables grow large fast.

Enable slow query logging in my.cnf:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1

Restart MySQL, let it run through a normal traffic period, then review:

mysqldumpslow -s t /var/log/mysql/mysql-slow.log

Check for missing indexes on the columns that get filtered and joined constantly in a delivery app — especially:

zone_id
store_id
user_id

If these aren't indexed, every query filtering orders or products by zone, store, or user forces a full table scan — which gets dramatically worse as order volume grows. Adding indexes here is typically low-risk and high-impact.

5. Check `innodb_buffer_pool_size`

This setting controls how much RAM MySQL's InnoDB engine uses to cache data and indexes in memory rather than reading from disk. The MySQL default is often a conservative 128MB — far too small for a production app with real traffic.

Check current value:

grep -i innodb_buffer_pool_size /etc/my.cnf

General guidance: on a server dedicated primarily to the database, this should be set to roughly 50–60% of total server RAM. On a shared server (running MySQL alongside PHP, a web server, and other services), it needs to be sized more conservatively to avoid starving other processes — undersizing it hurts database performance, but oversizing it on a memory-constrained box can cause instability elsewhere on the server.

6. Check Resource Usage During Peak Traffic

Numbers only tell part of the story — actually watching CPU and RAM behavior during real traffic spikes shows where the bottleneck lives.

htop

Run this during a known peak period (lunch/dinner rush, for a food delivery platform) and capture a screenshot. Look specifically at:

Whether CPU is pegged at 100% across cores (compute-bound — likely PHP-FPM or unoptimized queries)
Whether RAM is nearly exhausted (memory-bound — risk of swapping or process kills)
Which specific processes are consuming the most resources

7. Confirm Redis Is Set Up for Cache and Sessions

By default, Laravel can use the file system or database for caching and session storage — both are far slower than Redis for high-frequency read/write operations, which matter a lot for a live-order-tracking app.

Check current driver in .env:

CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis

If Redis isn't installed or configured, setting it up is one of the more impactful upgrades available — it moves session reads/writes and cache lookups out of disk I/O entirely and into memory, which noticeably speeds up dashboard loads and repeated data access (store listings, zone data, category trees) that 6amMart queries constantly.

8. Check Product and Store Image Optimization

Unoptimized images are an easy thing to overlook but a common cause of "slow" perception even when the backend is fast — especially on the storefront and product listing pages where dozens of images load per screen.

Things to verify:

Are uploaded images being resized/compressed on upload, or served at original size?
Is a CDN or proper cache-control header in place for static assets?
Are images served in modern formats (WebP) where supported?

Summary

Performance issues on a Laravel-based platform like 6amMart are almost always a combination of a few of these factors rather than one single cause. Working through this checklist in order — application-level caching first, then background job processing, then database indexing and memory allocation, then infrastructure-level caching (Redis) and asset delivery — tends to surface the real bottleneck efficiently rather than guessing.

We'll report back findings and fixes against each item above.