Object Pooling
Also Known As
object pool pattern
resource pool
instance pool
TL;DR
Reusing a fixed set of pre-initialised expensive objects rather than creating and destroying them on every request — reducing allocation overhead.
Explanation
Object pooling maintains a pool of reusable objects (database connections, HTTP clients, worker threads) that are checked out, used, and returned rather than instantiated fresh each time. In traditional PHP request-per-process model, object pools within a single request have limited value — the process dies anyway. They become highly relevant in long-running PHP contexts: Swoole coroutines, RoadRunner workers, or CLI queue workers that handle many tasks. Database connection pools (pgBouncer, ProxySQL) operate at the infrastructure level and benefit all PHP architectures. In-process pools in PHP-FPM should be evaluated carefully — memory is not shared between workers.
Common Misconception
✗ Object pooling is only relevant in languages with expensive object creation. In PHP long-running processes (Swoole, RoadRunner, workers) reuse expensive objects like HTTP clients, parser instances, and compiled templates via pools — eliminating repeated initialisation overhead across requests.
Why It Matters
Object pooling reuses expensive-to-create objects (database connections, HTTP clients, thread contexts) — eliminating repeated construction overhead in high-throughput PHP-FPM or async workloads.
Common Mistakes
- Not resetting object state before returning to pool — a 'dirty' object from one request affects the next.
- Pool size not matched to concurrency — too small causes wait queues; too large wastes memory.
- Pooling cheap objects — the pool management overhead exceeds the construction savings for simple objects.
- Not handling exceptions that leave an object in an invalid state — the broken object must not return to the pool.
Code Examples
✗ Vulnerable
// Creating a new HTTP client on every request — expensive:
function callApi(string $url): array {
$client = new GuzzleHttp\Client(['timeout' => 5]); // New client each call
return $client->get($url)->json();
// Guzzle clients are reusable — inject a shared instance instead
}
✓ Fixed
// Reuse expensive objects rather than constructing and destroying repeatedly
class PdfRendererPool {
private \SplStack $pool;
public function __construct(private int $size = 4) {
$this->pool = new \SplStack();
for ($i = 0; $i < $size; $i++) {
$this->pool->push(new PdfRenderer()); // pre-warm
}
}
public function acquire(): PdfRenderer {
return $this->pool->isEmpty()
? new PdfRenderer() // overflow — create temporary
: $this->pool->pop();
}
public function release(PdfRenderer $r): void {
if ($this->pool->count() < $this->size) {
$this->pool->push($r); // return to pool
}
// else let it GC — pool is full
}
}
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
24
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
Amazonbot 8
Perplexity 3
Unknown AI 2
Google 2
SEMrush 2
Majestic 1
Ahrefs 1
Also referenced
How they use it
crawler 18
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Medium
⚡ Quick Fix
PHP-FPM resets state between requests so object pooling within a request is rarely worthwhile — in Swoole/RoadRunner persistent workers, pool expensive-to-create objects (DB connections, HTTP clients)
📦 Applies To
PHP 7.0+
web
cli
queue-worker
🔗 Prerequisites
🔍 Detection Hints
Recreating expensive objects per request in Swoole worker; HTTP client instantiated per API call; PDO connection opened per query in long-running worker
Auto-detectable:
✗ No
blackfire
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: High
Context: File
Tests: Update