Swoole / OpenSwoole
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list blackfire and swoole-dashboard, but these are profiling/monitoring tools rather than static analyzers that catch misuse at development time. Issues like blocking DB calls inside coroutines, shared mutable static state leaking between requests, and memory leaks in long-lived workers are silent during development and only surface under concurrent load or in production — automated detection is explicitly marked 'no' in the metadata.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix suggests using Laravel Octane as the simplest entry point, but even that is a significant integration step. Common mistakes like blocking DB calls inside Swoole, shared mutable static state, and not using async clients require auditing and refactoring every database call, every static reference, and every I/O operation across the codebase — this is inherently cross-cutting and not localized to a single component.
Closest to 'strong gravitational pull' (e7). Swoole/OpenSwoole applies to web, api, and queue-worker contexts — broad reach across the application. The persistent-process model fundamentally changes how PHP behaves: every future maintainer must understand request isolation, coroutine semantics, memory management in long-lived workers, and the prohibition on blocking calls. Every new feature or library added must be evaluated for Swoole compatibility, imposing a persistent productivity tax that shapes nearly every architectural decision.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The canonical misconception is that 'Swoole makes all PHP faster,' when in reality it only benefits high-concurrency I/O workloads and adds significant complexity for sequential PHP. Beyond this, the persistent-process model contradicts traditional PHP's shared-nothing, request-scoped execution model that developers know by default — static state, superglobals, and singleton patterns that are harmless in FPM become dangerous cross-request contamination bugs in Swoole, directly contradicting years of PHP developer intuition.
Also Known As
TL;DR
Explanation
Swoole adds coroutines, async MySQL/Redis/HTTP clients, WebSocket server, and an event-driven HTTP server as a C extension. Workers stay alive between requests. Non-blocking I/O allows coroutine scheduler to handle many concurrent connections with one worker.
Common Misconception
Why It Matters
Common Mistakes
- Blocking DB calls inside Swoole
- Shared mutable static state between coroutines
- Not using Swoole async clients
- Memory leaks in long-lived workers
Code Examples
$server->on('request', function($req,$resp) {
$result = $pdo->query('SELECT..'); // Blocks all coroutines!
});$server->on('request', function($req,$resp) {
go(function() use($resp) {
$db = new Swoole\Coroutine\MySQL();
$result = $db->query('SELECT..'); // Non-blocking
$resp->end(json_encode($result));
});
});