Week 26: Caching & Performance

1. OPcache

PHP is interpreted — without OPcache, every single request re-parses and re-compiles your PHP source files into bytecode from scratch, every time. OPcache caches that compiled bytecode in shared memory, skipping parsing entirely on every request after the first:

opcache.enable = 1
opcache.memory_consumption = 256      ; MB of shared memory for cached bytecode
opcache.max_accelerated_files = 20000 ; enough to cover every file in a large app
opcache.validate_timestamps = 0       ; production: never re-check if a file changed
opcache.revalidate_freq = 0

validate_timestamps = 0 is the setting that matters most, and the one most likely to confuse someone new to it: with it off, OPcache never re-checks whether a source file has changed — it just keeps serving the cached bytecode forever. That's exactly right for production (files don't change without a deliberate deploy), but wrong for local development, where you expect every saved change to take effect immediately.

opcache.validate_timestamps = 1  ; check on every request (or few requests) if the file changed
opcache.revalidate_freq = 0      ; check every single request -- fine for dev, too slow for prod

2. PHP-FPM Tuning

PHP-FPM (FastCGI Process Manager) is what actually runs PHP behind Nginx in production (previewed in Week 1, covered fully in Week 28) — a pool of worker processes, each handling one request at a time:

pm = dynamic
pm.max_children = 50      ; hard ceiling on concurrent PHP processes
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15

pm.max_children is a memory budget decision as much as a performance one: each worker process consumes real memory, so the right value is roughly (available RAM) / (memory per PHP process), not an arbitrarily large number. Setting it too high risks the server running out of memory under load; too low means requests queue up waiting for a free worker even when CPU and memory both have headroom.

3. Redis Caching Patterns

Beyond Week 24's WordPress-specific object cache, the same Redis patterns apply directly in Laravel:

<?php

use Illuminate\Support\Facades\Cache;

function getPopularProjects(): \Illuminate\Support\Collection {
    return Cache::remember('popular_projects', now()->addMinutes(15), function () {
        return Task::withCount('tags')->orderByDesc('tags_count')->limit(10)->get();
    });
}

Cache::remember() is the cache-aside pattern spelled out explicitly: check the cache first; on a miss, run the expensive operation, store the result, and return it; on a hit, skip straight to returning the cached value. This is the same idea as Week 24's wp_cache_get/wp_cache_set pair, wrapped into one call.

<?php

function getExchangeRate(string $currency): float {
    return Cache::remember("exchange_rate:{$currency}", now()->addHour(), function () use ($currency) {
        return Http::get("https://api.example.com/rates/{$currency}")->json('rate');
    });
}

Caching an external API call is often the highest-leverage cache in a real application — it avoids both the latency and the reliability risk of a third-party service on every single request, not just the database load a query cache saves.

4. Cache Invalidation

"There are only two hard things in computer science: cache invalidation and naming things" is a cliché precisely because it's true. A cache that returns stale data is often worse than no cache at all — the two main strategies:

<?php
// Accept staleness for up to 15 minutes, in exchange for simplicity
Cache::remember('popular_projects', now()->addMinutes(15), fn () => /* ... */);

<?php

class TaskController extends Controller
{
    public function update(UpdateTaskRequest $request, Task $task)
    {
        $task->update($request->validated());

        Cache::forget('popular_projects'); // invalidate immediately -- next read recomputes

        return redirect()->route('tasks.index');
    }
}

TTL expiration is simpler but accepts a window of staleness; explicit invalidation is always fresh but requires remembering to call Cache::forget() at every single write path that could affect the cached value — miss one, and that cache silently goes stale with no expiration to eventually correct it. Real systems often combine both: explicit invalidation as the primary mechanism, with a TTL as a safety net for any invalidation path that gets missed.

5. Query Optimization & Indexing

Week 6 introduced keys for relationships; an index is a separate, deliberate structure that makes lookups on a specific column fast — without one, a WHERE clause on a large table forces a full table scan:

EXPLAIN SELECT * FROM tasks WHERE user_id = 42 AND is_done = false;

EXPLAIN's output shows whether MySQL used an index (type: ref or better) or scanned every row (type: ALL) — ALL on a large table is the signal an index is missing.

<?php

Schema::table('tasks', function (Blueprint $table) {
    $table->index(['user_id', 'is_done']); // a composite index, matching this exact query pattern
});

A composite index on (user_id, is_done) — column order matters — speeds up exactly this query pattern (filtering by both columns together, or by user_id alone, since it's the leftmost column) without the overhead of maintaining two separate single-column indexes. Every index also has a cost: it speeds up reads but slows down writes (each INSERT/UPDATE must also update every index), so indexing every column "just in case" is its own mistake — index the columns your actual slow queries filter or join on, confirmed with EXPLAIN, not by guessing.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.