Nuffing.com

The Computer History Museum, based in Mountain View, California, looks like a fine way to spend an afternoon for anyone interested in, well, the history of computers. And if that description fits you but you’re not in California, then rejoice, because CHM recently launched OpenCHM, an excellent online portal designed to allow exploration of the museum from afar.

You can, of course, just click around to see what catches your eye, but if that feels too unfocused, you can also go straight to the collection highlights. As you might expect, these include a solid selection of early computers and microcomputers, along with photos, records, and other objects of historic import. Several objects predate the information age, including a Jacquard loom and a copy of The Adams Cable Codex, a fascinating 1894 book that catalogs hundreds of code words that were used to save space when sending messages via cable. Happily, there’s a full scan of the same book at the Internet Archive, because the CHM’s documentation on the latter is rather minimal.

This is the case throughout the site. In fairness, OpenCHM is still in beta, and hopefully the item descriptions will be fleshed out as the site develops—but as it stands, their terse nature means that some of the objects on show are disappointingly inscrutable. For example, it took a bit of googling to work out what on earth a klystron is, and the CHM’s description isn’t much help, noting only that “This item is mounted on a wooden base.” (For the record, a klystron is a vacuum tube amplifier that looks cool as hell.)

Still, such quibbles aside, there’s a wealth of material to explore here, and on the whole, Open CHM makes doing so both easy and enjoyable. It provides multiple entry points to the collection. In addition to the aforementioned highlights page and a series of curated collections, there’s something called the “Discovery Wall”. This is described as “a dynamic showcase of artifacts chosen by online visitors”, and it’s certainly interesting to see what catches people’s attention. At the time of our virtual visit, items on display on the Discovery Wall included an alarmingly yellow Atari t-shirt from 1977, a Tamagotchi (in its original packaging!), a placard from the 2023 Writers’ Guild strike (“Don’t let bots write your shows!”) and a Microsoft PS/2 mouse, the mere sight of which is likely to cause shudders in anyone with memories of flipping one of these over to pull out the trackball and clean months’ worth of accumulated crud from the two little rollers inside.

Perhaps the single most poignant item we came across, however, is a copy of Ted Nelson’s self-published 1974 opus Computer Lib/Dream Machines, which promoted computer literacy and the liberation Nelson hoped it would bring. The document is strikingly forward-thinking—amongst other things, it predicted hypertext, of which Nelson was an early proponent—but the technoutopianism on display seems both charmingly innocent and painfully naïve today. “New Freedoms Through Computer Screens”, promises the rear cover. If only they knew.

Your Laravel application felt fast during development.

Pages loaded instantly. Queries returned results in milliseconds. Everything seemed under control.

Then you deployed to production.

Traffic increased. Data grew. Users started complaining: “The site feels slow.”

This is a classic Laravel problem — and no, it’s usually not caused by PHP or Blade templates.

👉 The real bottleneck is almost always the database.

In production, inefficient queries don’t just slow down a page — they compound under load, drain server resources, and quietly kill performance.

In this guide, you’ll learn how to systematically optimize Laravel databases in production using three essential tools:

1. Database Indexes

2. EXPLAIN (Query Execution Plans)

3. MySQL Slow Query Log

Used together, these tools turn guessing into measurable optimization.

Why Database Optimization Matters (More Than You Think)

A few uncomfortable truths:

• A 1-second delay can reduce conversions by 7%

• Full table scans grow exponentially with data

• What works with 10,000 rows fails miserably at 1 million

• Laravel doesn’t automatically fix bad queries

Your database doesn’t care how elegant your Eloquent code looks — it only cares how much work it has to do.

Optimization is about reducing work.

Database Indexes: The Foundation of Performance

What Is an Index (Really)?

Without an index, MySQL must scan every row to find matching data.

Think of it like this:

Indexes turn O(n) scans into O(log n) lookups.

When Should You Add Indexes?

Create indexes on columns that are:

Avoid indexing:

Basic Laravel Example

$orders = Order::where('user_id', $userId)->get();

If orders.user_id is not indexed, MySQL scans the entire table.

Fix via Migration

Schema::table('orders', function (Blueprint $table) {
    $table->index('user_id');
});

Now MySQL can jump straight to relevant rows.

Composite Indexes (Where Most Apps Win)

Real queries rarely filter on just one column.

$orders = Order::where('user_id', $userId)
               ->where('status', 'paid')
               ->orderBy('created_at', 'desc')
               ->get();

Optimal Index

Schema::table('orders', function (Blueprint $table) {
    $table->index(['user_id', 'status', 'created_at']);
});

⚠️ Index order matters

• MySQL can use (user_id, status)

• It cannot efficiently use (status, created_at) alone

Always index columns in the same order your queries filter them.

Indexing Mistakes to Avoid

❌ Indexing every column
❌ Guessing instead of measuring
❌ Ignoring write performance
❌ Indexing low-cardinality fields alone

Indexes speed up reads but slow down writes. Balance is key.

EXPLAIN: Understanding What MySQL Actually Does

Writing a query doesn’t mean MySQL executes it the way you expect.

EXPLAIN shows the truth.

Using EXPLAIN in Laravel

Raw SQL (Recommended)

$plan = DB::select(
    'EXPLAIN SELECT * FROM orders WHERE user_id = ?',
    [$userId]
);

dd($plan);

MySQL Console

EXPLAIN SELECT * FROM orders WHERE user_id = 10;

The Most Important EXPLAIN Columns

type (Scan Method)

key

• The index actually used

• NULL = no index used ❌

rows

• Estimated rows scanned

• Smaller is always better

Extra

• Using filesort → Slow sorting

• Using temporary → Temp table created

• Using index → Index-only query (excellent)

Example: Query Without Index

EXPLAIN SELECT * FROM products WHERE category_id = 5;

Result:

• type = ALL

• key = NULL

• rows = 600000

🚨 MySQL scanned the entire table.

After Adding Index

CREATE INDEX idx_category_id ON products (category_id);

EXPLAIN SELECT * FROM products WHERE category_id = 5;

Result:

• type = ref

• key = idx_category_id

• rows = 120

✔ Massive improvement with zero code changes.

EXPLAIN Golden Rules

Slow Query Log: Catching Problems in Real Traffic

Some performance issues only appear in production.

That’s where Slow Query Log shines.

What Is Slow Query Log?

It records queries that exceed a time threshold.

Think of it as a black box recorder for your database.

Enable Slow Query Log (Temporary)

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 1;

Queries taking longer than 1 second will be logged.

Enable Permanently (Recommended)

Edit MySQL config:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Restart MySQL:

sudo systemctl restart mysql

Sample Slow Query Log Entry

Query_time: 2.94
Rows_examined: 184732
SELECT * FROM orders
WHERE user_id = 123
ORDER BY created_at DESC;

This query scanned 184,732 rows to return a few records.

That’s your optimization target.

Analyze Slow Queries

Built-in Tool

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

Professional Tool (Recommended)

pt-query-digest /var/log/mysql/mysql-slow.log

This gives:

• Query frequency

• Total execution time

• Average latency

• Rows examined

Laravel-Level Monitoring

Laravel Telescope (Great for QA)

composer require laravel/telescope
php artisan telescope:install
php artisan migrate

View query execution time directly in the dashboard.

Debugbar (Local Only)

composer require barryvdh/laravel-debugbar --dev

Never use Debugbar in production.

A Real Optimization Workflow

1. Enable slow query log

2. Identify worst queries

3. Run EXPLAIN

4. Add or adjust indexes

5. Refactor queries if needed

6. Measure before & after

7. Deploy and monitor

Optimization without measurement is guesswork.

Real-World Case: Product Search Optimization

The Problem Query

Product::where('name', 'LIKE', '%laptop%')
       ->where('is_active', 1)
       ->orderBy('created_at', 'desc')
       ->paginate(20);

EXPLAIN showed:

• Full table scan

• Filesort

• 800k rows scanned

Fix 1: Full-Text Search

Schema::table('products', function (Blueprint $table) {
    $table->fullText('name');
});

Product::whereFullText('name', 'laptop')
       ->where('is_active', 1)
       ->paginate(20);

Fix 2: Composite Index

Schema::table('products', function (Blueprint $table) {
    $table->index(['is_active', 'created_at']);
});

Results

| Metric       | Before  | After   |
| ------------ | ------- | ------- |
| Rows scanned | 850,000 | 220     |
| Query time   | 3.1s    | 0.04s   |
| CPU usage    | High    | Minimal |

Same app. Same data.
Just smarter database usage.

Release Date: January 23, 2025

Package Version: v4.0.0

Summary

Laravel Debugbar v4.0.0 marks a major release with package ownership transferring from barryvdh/laravel-debugbar to fruitcake/laravel-debugbar. This version brings php-debugbar 3.x support and includes several new collectors and improvements for modern Laravel applications.

• HTTP Client collector for tracking outbound API requests
• Inertia collector for Inertia.js data tracking
• Improved Livewire support for versions 2, 3, and 4
• Remove jQuery in favor of modern JS
• Improved performance and delayed rendering
• Laravel Octane compatibility for long-running processes
• And more

What’s New

HTTP Client Collector

This release adds a new collector that tracks HTTP client requests made through Laravel’s HTTP client. The collector provides visibility into outbound API calls, making it easier to debug external service integrations and monitor response times.

Inertia Collector

For applications using Inertia.js, the new Inertia collector tracks shared data and props passed to Inertia components. This helps debug data flow in Inertia-powered applications.

Enhanced Livewire Support

The debugbar now includes improved component detection for Livewire versions 2, 3, and 4. This provides better visibility into Livewire component lifecycle events and data updates across all currently supported Livewire versions.

Laravel Octane Compatibility

This version includes better handling for Laravel Octane and other long-running server processes. The debugbar now properly manages state across requests in persistent application environments.

Cache Usage Estimation

The cache widget now displays estimated byte usage, giving developers better insight into cache memory consumption during request processing.

Debugbar Position and Themes

This version has many UI improvements and settings like debugbar position, auto-hiding empty collectors, themes (Dark, Light, Auto), and more:

Breaking Changes

Package Ownership and Installation

The package has moved from barryvdh/laravel-debugbar to fruitcake/laravel-debugbar, requiring manual removal and reinstallation:

composer remove barryvdh/laravel-debugbar --dev --no-scripts
composer require fruitcake/laravel-debugbar --dev --with-dependencies

The namespace has changed from the original structure to Fruitcake\LaravelDebugbar. You’ll need to update any direct references to debugbar classes in your codebase.

Removed Features

Several features have been removed in this major version:

• Socket storage support has been removed
• Lumen framework support is no longer included
• PDO extension functionality has been dropped

Configuration Changes

Default configuration values have been updated, and deprecated configuration options have been removed. Review your config/debugbar.php file and compare it with the published configuration from the new package.

Upgrade Notes

This is not a standard upgrade. You must manually remove the old package and install the new one using the commands shown above. After installation, update any namespace references in your code from the old barryvdh namespace to Fruitcake\LaravelDebugbar.

Review your configuration file for deprecated options and compare with the new defaults. The package maintains compatibility with Laravel 9.x through 12.x. See the upgrade docs for details on upgrading from 3.x to 4.x.

References