OPcache is a built-in PHP extension that stores precompiled script bytecode in shared memory, eliminating the need to parse and compile PHP files on every request.

; php.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0 ; disable in production for max speed

Enabling OPcache typically gives a significant performance boost (often 2-3x) with essentially no code changes required.

The N+1 problem occurs when fetching a list of records triggers one additional query per record to load related data, instead of one combined query.

// Laravel example - cache expensive query for 1 hour
$products = Cache::remember('featured_products', 3600, function () {
    return Product::where('featured', true)->get();
});

The right strategy depends on how often data changes - full-page caching suits mostly-static content, while data caching suits frequently-read but rarely-written data.

Both are in-memory key-value stores used to cache data that's expensive to compute or fetch repeatedly, avoiding hitting the database on every request.

// Laravel with Redis (config/cache.php: 'default' => 'redis')
Cache::put('user:' . $id, $userData, 600); // store for 10 min
$user = Cache::get('user:' . $id);

// Raw Redis client
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->set('user:1', json_encode($userData));
$redis->expire('user:1', 600);

// Analyzing a slow query
EXPLAIN SELECT * FROM orders WHERE customer_id = 5 AND status = 'pending';

// Adding a composite index
CREATE INDEX idx_customer_status ON orders (customer_id, status);

// Selecting only needed columns
$users = User::select('id', 'name', 'email')->get();

// Lazy loading (default) - triggers query when accessed
$post = Post::find(1);
echo $post->author->name; // separate query fired here

// Eager loading - loads relationship upfront
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name; // no extra queries
}

Rule of thumb: if you're looping over a collection and accessing a relationship inside the loop, eager load it to avoid N+1 queries.

// Basic manual timing
$start = microtime(true);
$result = expensiveOperation();
$duration = microtime(true) - $start;
error_log("Operation took: {$duration}s");

// Memory usage
echo memory_get_peak_usage(true) / 1024 / 1024 . ' MB';

Composer's default autoloader (PSR-4) resolves class names to file paths dynamically. In production, this can be optimized into a fast, precomputed lookup.

# Development - flexible but slower
composer dump-autoload

# Production - optimized classmap, much faster
composer dump-autoload --optimize
# or during install/update
composer install --optimize-autoloader --no-dev

The --optimize-autoloader flag is a standard part of production deployment scripts alongside opcache and config caching.

Most production PHP setups use horizontal scaling for the application layer combined with vertical scaling on the database layer.

// Bad - recalculates count() every iteration
for ($i = 0; $i < count($items); $i++) { ... }

// Good
$total = count($items);
for ($i = 0; $i < $total; $i++) { ... }

// Bad - loads whole file
$data = file_get_contents('huge.csv');

// Good - streams line by line
$handle = fopen('huge.csv', 'r');
while (($line = fgets($handle)) !== false) {
    // process line
}
fclose($handle);