Laravel Concurrency::run(): load three slow dashboard queries in parallel

Your Inertia dashboard shows revenue, signups and open tickets. Each number takes 400 ms to compute, they don’t depend on each other, and PHP runs them one after another: 1.2 seconds before the page even starts rendering. Laravel can run them side by side with one call that most apps have never used.

What Concurrency is and why people miss it#

Concurrency arrived in Laravel 11.23 (September 2024), in the same release as defer() and Cache::flexible. It has its own docs page, tucked between Collections and Context, and most tutorials still reach for a queue or nothing at all.

Under the hood, Laravel serializes each closure with laravel/serializable-closure, starts a hidden php artisan invoke-serialized-closure process per closure, waits for all of them, and unserializes the results. Your closures run with a fully booted app: config, database, Eloquent, facades.

The usual way vs the gem#

public function __invoke()
{
    return Inertia::render('Dashboard', [
        'revenue' => $this->revenue(),     // ~400 ms
        'signups' => $this->signups(),     // ~400 ms
        'tickets' => $this->openTickets(), // ~400 ms
    ]);                                    // ≈ 1.2 s
}

use Illuminate\Support\Facades\Concurrency;

public function __invoke()
{
    $stats = Concurrency::run([ 
        'revenue' => fn () => Order::thisMonth()->sum('total'),
        'signups' => fn () => User::where('created_at', '>=', now()->subWeek())->count(),
        'tickets' => fn () => Ticket::open()->count(),
    ]);                                    // ≈ 0.6 s

    return Inertia::render('Dashboard', $stats);
}

Named keys come back as named keys, so $stats drops straight into the props. With a plain list, destructure: [$revenue, $signups] = Concurrency::run([...]).

What we measured#

Each task was usleep(400_000), run from a booted Laravel 13.37 app on PHP 8.3 with the default process driver:

The last three lines are the catch. Each call boots a fresh PHP process per closure, and that costs about 200 ms here. At 100 ms per task, the concurrent version was already slower than doing the work in sequence. Concurrency pays off when the tasks are slow and independent: several hundred milliseconds each, at least two of them.

Real-world example: a dashboard with an external API#

Concurrency shines when one of the slow tasks waits on the network. Here the Stripe balance call and two heavy aggregates run together, with a timeout so a hung API can’t hold the page forever:

<?php

namespace App\Http\Controllers;

use App\Models\Order;
use App\Models\Ticket;
use Illuminate\Support\Facades\Concurrency;
use Illuminate\Support\Facades\Http;
use Inertia\Inertia;

class DashboardController
{
    public function __invoke()
    {
        $stats = Concurrency::run([
            'revenue' => fn () => Order::whereMonth('created_at', now()->month)->sum('total'),
            'tickets' => fn () => Ticket::where('status', 'open')->count(),
            'balance' => fn () => Http::withToken(config('services.stripe.secret'))
                ->get('https://api.stripe.com/v1/balance')
                ->json('available.0.amount'),
        ], timeout: 5); // seconds, per task (process driver only)

        return Inertia::render('Dashboard', $stats);
    }
}

<script setup lang="ts">
defineProps<{ revenue: number; tickets: number; balance: number | null }>()
</script>

<template>
    <dl class="grid grid-cols-3 gap-4">
        <div><dt>Revenue this month</dt><dd>{{ revenue }}</dd></div>
        <div><dt>Open tickets</dt><dd>{{ tickets }}</dd></div>
        <div><dt>Stripe balance</dt><dd>{{ balance ?? '—' }}</dd></div>
    </dl>
</template>

Exceptions, timeouts and Context#

Exceptions are rethrown in the parent. A child that throws new RuntimeException('boom in child') surfaced in the parent as RuntimeException: boom in child, so your normal try/catch and the exception handler work. The other results are lost: one failure fails the whole call. Catch inside the closure if a missing number is acceptable:

'balance' => function () {
    try {
        return Http::timeout(3)->get('https://api.stripe.com/v1/balance')->json('available.0.amount');
    } catch (\Throwable $e) {
        report($e);
        return null; // the dashboard shows "—" instead of a 500
    }
},

Timeouts kill the child. With timeout: 1 and a task that sleeps three seconds, the parent got an Illuminate\Process\Exceptions\ProcessTimedOutException. The timeout applies to each task, on the process driver only.

Context travels. The process driver passes the current Context to each child, so Context::get('request_id') inside a closure returned the parent’s value and log lines from the children carry the same request id.

Concurrency::defer(): parallel and after the response#

When you don’t need the results, Concurrency::defer() combines the two gems: the closures run concurrently, after the response is sent, like defer():

Concurrency::defer([
    fn () => Crm::syncOrder($order->id),
    fn () => Analytics::track('order.placed', $order->id),
]);

Gotchas#

One closure per line. This one cost us ten minutes. Concurrency::run([fn () => 'A', fn () => 'B']) returned ["A","A"]. Closures are serialized by reading their source code, and laravel/serializable-closure can’t tell apart two closures with the same signature on the same line. Its README says so. Put each closure on its own line, which you want for readability anyway.

Captured objects are serialized, not shared. A closure that does use ($user) gets a copy: an Eloquent model in use arrived intact in our test, changes made in the child never reach the parent, and an object of a class the child can’t autoload fails with an “incomplete object” error. Anonymous classes can’t be serialized at all.

No transactions across children. Each child opens its own database connection. Don’t split one unit of work across closures and expect DB::transaction() in the parent to cover them.

The fork driver is CLI-only. It is faster (no new PHP boot) and needs composer require spatie/fork, but PHP can’t fork inside a web request. Use it in Artisan commands and queued jobs: Concurrency::driver('fork')->run([...]).

Use sync in tests if you mock things. Fakes like Http::fake() live in the parent process; a child boots a fresh app without them. In our test, a faked URL inside Concurrency::run() made a real request (and failed with a ConnectionException), while the sync driver returned the fake. Add <env name="CONCURRENCY_DRIVER" value="sync"/> to phpunit.xml.

Try it yourself#

php artisan tinker

use Illuminate\Support\Benchmark;
use Illuminate\Support\Facades\Concurrency;

Benchmark::measure([
    'sequential' => fn () => [usleep(400_000), usleep(400_000), usleep(400_000)],
    'concurrent' => fn () => Concurrency::run([
        fn () => usleep(400_000),
        fn () => usleep(400_000),
        fn () => usleep(400_000),
    ]),
]);
// ['sequential' => ~1200.0, 'concurrent' => ~600.0] (ms)

How useful is this?#

Recap#

• Concurrency::run() runs each closure in its own PHP process and returns all results, by position or by key.
• It saved half the time on three 400 ms tasks, and cost ~200 ms on a single one. Measure.
• Child exceptions are rethrown in the parent; timeout: kills slow children; Context goes along.
• Concurrency::defer() runs them in parallel after the response.
• One closure per line, autoloadable classes only, fork in the CLI, sync in tests.

FAQ#

Next steps#

• Laravel defer(): run code after the response
• Cache::flexible: serve stale cache while it refreshes
• Laravel Context: one request id everywhere
• Laravel docs: Concurrency

Sources#

• Laravel docs: Concurrency (drivers, named results, timeouts, defer)
• Illuminate\Concurrency\ProcessDriver, which starts invoke-serialized-closure and passes the Context
• laravel/serializable-closure README, on closures defined on the same line
• Laravel 11.23 release (Concurrency, defer(), Cache::flexible)