Forem: Edmond

The multithreaded PHP

Edmond — Sat, 18 Apr 2026 10:57:40 +0000

It may seem like PHP + Threads + ThreadPool isn’t anything special. After all, we already have Parallel. But what’s coming this summer is another small step toward a completely new and unfamiliar PHP, a PHP that can solve modern problems more efficiently and with cleaner code.

A lot of things are happening here for the first time:

• Seamless combination of threads and coroutines. The thread creation function is called spawn_thread for a reason, hinting that the returned object behaves very much like a coroutine. This means it can be composed with await, await_all().

• New ABI for object copying. After a lot of hesitation, I added a dedicated method directly into the Zend Object ABI for copying objects between threads. Resources received something similar.

• Object movement like in Rust. We talked about this a year ago, that PHP might adopt move semantics. And here it is. FutureState can move itself between threads.

• WeakReference is handled correctly when crossing thread boundaries.

Can you feel how this opens the door to cleaner code without hacks? Things that developers used to simulate with processes, Redis, Python helpers, or massive libraries can now be done in just 10–20 lines of code.

<?php

use Async\ThreadPool;
use function Async\spawn;

// This function is executed in a worker thread.
// GD operations are CPU-bound — exactly the kind of tasks that benefit from threads.
function processImage(string $src, string $outDir, int $maxWidth): array
{
    $info = getimagesize($src);
    if ($info === false) {
        throw new \RuntimeException("Failed to read: $src");
    }

    // Open source
    $original = match ($info[2]) {
        IMAGETYPE_JPEG => imagecreatefromjpeg($src),
        IMAGETYPE_PNG  => imagecreatefrompng($src),
        IMAGETYPE_WEBP => imagecreatefromwebp($src),
        default        => throw new \RuntimeException("Unsupported format: $src"),
    };

    // Resize while preserving aspect ratio
    [$origW, $origH] = [$info[0], $info[1]];
    $scale    = min(1.0, $maxWidth / $origW);
    $newW     = (int) ($origW * $scale);
    $newH     = (int) ($origH * $scale);
    $resized  = imagescale($original, $newW, $newH, IMG_BICUBIC);
    imagedestroy($original);

    // Convert to grayscale
    imagefilter($resized, IMG_FILTER_GRAYSCALE);

    // Save to output directory
    $outPath = $outDir . '/' . basename($src, '.' . pathinfo($src, PATHINFO_EXTENSION)) . '_thumb.jpg';
    imagejpeg($resized, $outPath, quality: 85);
    $outSize = filesize($outPath);
    imagedestroy($resized);

    return [
        'src'     => $src,
        'out'     => $outPath,
        'size_kb' => round($outSize / 1024, 1),
        'width'   => $newW,
        'height'  => $newH,
    ];
}

spawn(function() {
    $srcDir  = '/var/www/uploads/originals';
    $outDir  = '/var/www/uploads/thumbs';
    $maxW    = 800;

    // List of files to process
    $files = glob("$srcDir/*.{jpg,jpeg,png,webp}", GLOB_BRACE);
    if (empty($files)) {
        echo "No files to process\n";
        return;
    }

    $pool = new ThreadPool(workers: (int) shell_exec('nproc') ?: 4);

    // map() preserves order — results[i] corresponds to files[i]
    $results = $pool->map($files, fn(string $path) => processImage($path, $outDir, $maxW));

    $totalKb = 0;
    foreach ($results as $r) {
        echo sprintf("%-40s → %s  (%dx%d, %.1f KB)\n",
            basename($r['src']), basename($r['out']),
            $r['width'], $r['height'], $r['size_kb']
        );
        $totalKb += $r['size_kb'];
    }

    echo sprintf("\nProcessed: %d files, total %.1f KB\n", count($results), $totalKb);
    $pool->close();
});

Yes, version 0.7.0 isn’t released yet, and there is still time to change or refine things. The most important open question is move semantics. How to make it clear in code that an object is being moved. Should the syntax reflect that?

Join the discussion about the new version. Your knowledge and experience can be valuable!

Async\Thread: running PHP in a separate thread | TrueAsync

True async/await, coroutines, and non-blocking I/O for PHP

true-async.github.io

Why does PHP need asynchrony?

Edmond — Fri, 17 Apr 2026 07:00:00 +0000

"The most dangerous phrase in the language is 'We've always done it this way.'" — Grace Hopper

PHP is one of the last major languages that still lacks built-in support for concurrent execution at the language level. Python has asyncio, JavaScript is natively built on an event loop, Go has goroutines, Kotlin has coroutines. PHP remains in the "one request — one process" paradigm, even though most real-world applications spend the majority of their time waiting for I/O (IO Bound).

The fragmentation problem

Today, asynchrony in PHP is implemented through extensions: Swoole, AMPHP, ReactPHP. Each creates its own ecosystem with incompatible APIs, its own database drivers, HTTP clients and servers.

This leads to critical problems:

Code duplication — each extension is forced to rewrite drivers for MySQL, PostgreSQL, Redis and other systems
Incompatibility — a library written for Swoole doesn't work with AMPHP, and vice versa
Limitations — extensions cannot make standard PHP functions (file_get_contents, fread, curl_exec) non-blocking, because they don't have access to the core
Barrier to entry — developers need to learn a separate ecosystem instead of using familiar tools

TrueAsync

True async/await, coroutines, and non-blocking I/O for PHP

true-async.github.io

Greedy Arrays in PHP

Edmond — Thu, 16 Apr 2026 15:42:13 +0000

In some optimized PHP applications, you may occasionally see “strange code” like $this->array = [] after heavy usage. There’s an array that held many elements, and then it suddenly gets cleared by assigning a new empty array. You might think, “that’s just how the author wrote it.” But most likely not — the author is probably familiar with the problem of greedy arrays in PHP.

The idea: PHP arrays can grow dynamically, but they do not shrink dynamically.

Example. Suppose you created a queue of 10,000 elements. You processed everything. But in reality, the memory remains allocated. Is this a problem? Yes. If you’re writing stateful applications, this can become an issue. Nothing seems wrong, yet your process keeps growing over time, and you can’t even figure out why. Sound familiar? Here’s the culprit.

That’s why for long-running PHP applications it’s recommended to always explicitly clear large arrays.

The operation $this->array = [] tells the PHP engine to fully release the entire memory block, after which the object property is assigned a constant empty array.

Why is it designed this way? Because automatic shrinking of data structures is one of the most complex algorithms. It either complicates the code significantly or leads to performance loss. So the decision in PHP is reasonable: do not shrink arrays automatically. However, this still remains a language limitation. How to solve it? Possibly by introducing a new garbage collector.

Parallel file downloading with cURL

Edmond — Thu, 16 Apr 2026 15:40:08 +0000

A consequence of full cURL integration into the EventLoop. The option CURLOPT_FILE => $fp tells #cURL to write output directly to a file, which goes through the async engine.

On Windows, since it does not handle file I/O descriptors properly, the code runs via IOCP + a thread pool. As a result, all 20 files are written not just concurrently, but actually in parallel. Hence the unusual performance boost.

On Linux, this would require only #io_uring, but it still needs some work.

<?php

use function Async\spawn;
use function Async\await_all;

// Directory where downloaded files will be stored
$downloadDir = __DIR__ . '/downloads';

// Create directory if it does not exist
if (!is_dir($downloadDir)) {
    mkdir($downloadDir, 0755, true);
}

// Prepare list of files to download (WordPress plugins)
$files = array_map(fn($slug) => [
    'url'      => "https://downloads.wordpress.org/plugin/{$slug}.zip",
    'filename' => "{$slug}.zip",
], [
    'classic-editor',
    'akismet',
    'contact-form-7',
    'jetpack',
    'woocommerce',
    'wordfence',
    'elementor',
    'yoast-seo',
    'wpforms-lite',
    'really-simple-ssl',
    'all-in-one-seo-pack',
    'updraftplus',
    'litespeed-cache',
    'w3-total-cache',
    'duplicate-post',
    'mailchimp-for-wp',
    'regenerate-thumbnails',
    'redirection',
    'cookie-law-info',
    'wp-super-cache',
]);

/**
 * Downloads a file using cURL and saves it to disk
 */
function downloadFile(string $url, string $savePath): array
{
    // Open file for writing
    $fp = fopen($savePath, 'wb');
    if ($fp === false) {
        return ['success' => false, 'error' => "Failed to open file: $savePath"];
    }

    // Initialize cURL session
    $ch = curl_init($url);

    // Configure cURL options
    curl_setopt_array($ch, [
        CURLOPT_FILE           => $fp,              // Write response directly to file
        CURLOPT_FOLLOWLOCATION => true,             // Follow redirects
        CURLOPT_MAXREDIRS      => 5,                // Max redirects
        CURLOPT_TIMEOUT        => 120,              // Max execution time
        CURLOPT_CONNECTTIMEOUT => 10,               // Connection timeout
        CURLOPT_USERAGENT      => 'PHP CURL Downloader/1.0',
        CURLOPT_FAILONERROR    => true,             // Fail on HTTP errors (4xx, 5xx)
    ]);

    // Execute request
    $ok    = curl_exec($ch);
    $error = curl_error($ch);
    $info  = curl_getinfo($ch);

    fclose($fp);

    // Handle failure: remove partial file
    if (!$ok) {
        unlink($savePath);
        return ['success' => false, 'error' => $error ?: "HTTP {$info['http_code']}"];
    }

    // Return download metadata
    return [
        'success'  => true,
        'filename' => basename($savePath),
        'bytes'    => $info['size_download'],
        'speed'    => round($info['speed_download'] / 1024, 1) . ' KB/s',
    ];
}

$startTime = microtime(true);

// Start parallel downloads
echo "Starting " . count($files) . " downloads in parallel...\n\n";

$coroutines = [];
foreach ($files as $file) {
    $savePath = $downloadDir . '/' . $file['filename'];

    // Log start of download
    echo "↓ Start: {$file['filename']}\n";

    // Spawn coroutine for each download
    $coroutines[] = spawn(fn() => downloadFile($file['url'], $savePath));
}

echo "\n";

// Wait for all coroutines to complete
[$results, $exceptions] = await_all($coroutines);

// Process successful/failed results
foreach ($results as $result) {
    if ($result['success']) {
        $kb = round($result['bytes'] / 1024, 1);
        echo "✓ {$result['filename']}: {$kb} KB  [{$result['speed']}]\n";
    } else {
        echo "✗ Error: {$result['error']}\n";
    }
}

// Handle coroutine-level exceptions
foreach ($exceptions as $i => $e) {
    echo "✗ Coroutine $i failed: {$e->getMessage()}\n";
}

// Print total execution time
$elapsed = round(microtime(true) - $startTime, 2);
echo "\nDone in {$elapsed}s. Files saved to: $downloadDir\n";

Laravel async vs Octane

Edmond — Fri, 03 Apr 2026 14:31:56 +0000

How much can you speed up Laravel if you handle requests in coroutines instead of blocking workers? We benchmarked TrueAsync (native PHP coroutines) against three Laravel Octane configurations.

The Benchmark

Environment

OS: WSL2 (Linux 5.15), 16 cores, 7.8 GB RAM
DB: PostgreSQL 16 (max_connections=500)
Load tool: k6, constant-arrival-rate, 1,000 req/s for 30 seconds

Parameter	TrueAsync FrankenPHP	Octane Swoole (NTS)	Octane Swoole (ZTS)	Octane FrankenPHP
PHP	8.6.0-dev (ZTS)	8.5.4 (NTS)	8.5.4 (ZTS)	8.5.4 (NTS)
Server	FrankenPHP (true-async fork)	Swoole 6.2.0	Swoole 6.2.0	FrankenPHP (official)
Laravel	13.2.0	13.2.0	13.2.0	13.2.0
Model	Coroutines (libuv)	Processes (fork)	Threads (ZTS)	Processes (fork)

Note: Swoole runs without coroutine mode here because Laravel is not adapted for it. In a pure synthetic test with coroutines, Swoole shows slightly better numbers than FrankenPHP + TrueAsync. Both servers reach ~10,000 req/s with 12 workers on synthetic loads.

Full benchmark repository: github.com/YanGusik/ta_benchmark

Workload

The /bench endpoint executes 10 sequential SQL queries against PostgreSQL: user lookup, post listing, INSERT a view record, UPDATE a counter, aggregations, TOP-N selections. Database: 100 users, 1,000 posts, growing post_views table.

This is a realistic workload, not a synthetic "Hello World".

Results

Throughput (req/s)

Workers	TrueAsync	Swoole NTS	Swoole ZTS	FrankenPHP Octane
4	989	183	185	189
8	993	342	341	346
12	990	483	476	489
16	987	599	601	556

With 16 workers, TrueAsync handles 987 req/s. The best Octane result is 601 req/s (Swoole ZTS), 64% less with the same worker count.

We gave blocking servers 16 workers to be generous. TrueAsync doesn't need them. Four workers handle 989 req/s, the same as sixteen. Coroutines yield on every PDO::query(), so one worker runs dozens of requests concurrently. While one coroutine waits for PostgreSQL, others keep working.

Median Latency (P50)

Workers	TrueAsync	Swoole NTS	Swoole ZTS	FrankenPHP Octane
4	28 ms	5,440 ms	5,320 ms	5,240 ms
8	27 ms	2,870 ms	2,900 ms	2,800 ms
12	28 ms	2,040 ms	2,050 ms	1,990 ms
16	29 ms	1,640 ms	1,660 ms	1,780 ms

29 ms vs 1,640 ms at 16 workers. 56x difference. Where do those seconds come from?

Phase	TrueAsync (4w)	Swoole (4w)
PHP execution	~5 ms	~5 ms
SQL I/O wait (10 queries)	~23 ms	~23 ms
Queue wait	~0 ms	~5,400 ms
Total	~28 ms	~5,440 ms

PHP and SQL run at identical speeds. The entire difference is queue wait: a blocking server can't start your request until the current one finishes. With TrueAsync, CPU utilization is higher because coroutines yield during I/O instead of blocking the worker.

No magic. Just better resource utilization.

Memory (under load)

Workers	TrueAsync	Swoole ZTS	FrankenPHP Octane
4	277 MB	508 MB	401 MB
8	286 MB	600 MB	417 MB
16	308 MB	765 MB	403 MB

In the blocking model, each worker is a separate process with a full Laravel copy: container, configuration, router, middleware, database manager. With TrueAsync, coroutines share a common bootstrap. Only per-request data (request, session, auth) is duplicated. Hence 308 MB vs 765 MB at 16 workers.

Key Takeaways

Tests are not something you should fully trust. Different scenarios are possible. However, there’s no magic here.

Even at maximum workers, TrueAsync wins by 30-40%. You could spin up 22-27 blocking workers to match throughput, but you'd still lose on latency and memory. And why use 22 workers when 4 will do?

The bottom line: for IO-bound workloads (which is most web apps), TrueAsync serves the same traffic with 5-6x fewer workers, 56x lower latency, and half the memory.