পাঠ্যক্রম খুলুন

প্রাথমিক পর্যায়

Connection Pooling: সীমিত database connection পুনর্ব্যবহার

Connection Pooling

এই পাঠের কুইজ ↓৬ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনVertical ও Horizontal Scaling: সার্ভার বড় করব, না বাড়াব ↗

এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

Connection establishment ও reuse-এর খরচ
PHP worker count থেকে DB connection budget
Pooler ও transaction boundary

সমস্যা দিয়ে শুরু

App replica চার থেকে বিশ করা হলো। Throughput বাড়ার বদলে PostgreSQL too many connections বলছে। প্রতিটি PHP worker নিজস্ব database connection রাখলে app capacity বাড়ানো database resource consumption-ও বাড়ায়। Pooling হলো সীমিত connection reuse ও borrowing-এর ব্যবস্থা; এটি অসীম concurrency তৈরি করে না।

সহজ করে বুঝি

একটি pool connection প্রস্তুত রাখে, borrower কাজ শেষে ফেরত দেয়। Pool পূর্ণ হলে wait বা reject policy লাগে। PHP-FPM request model, long-lived worker ও external pooler-এর lifecycle আলাদা। Laravel DB connection object ব্যবহার করলেই সব PHP process এক shared pool ব্যবহার করছে না। PostgreSQL-এর সামনে PgBouncer connection multiplex করতে পারে। Session pooling ও transaction pooling-এর contract আলাদা; session-scoped state transaction mode-এ একই server connection-এ থাকবে না।

পরিচিত একটি উপমা

একটি office-এ সীমিত meeting room booking system আছে। কর্মী বাড়ালেই room বাড়ে না। Room খালি হওয়ার অপেক্ষায় কতক্ষণ থাকবেন, কে অগ্রাধিকার পাবে এবং কাজ শেষে room ফেরত দেবেন কীভাবে—এসব policy দরকার। Reservation ধরে রেখে বাইরে ফোন করলে অন্যদের অপেক্ষা বাড়ে।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

অনেক application client connection pooler-এ আসে।

Diagram-এর text flow দেখুন

flowchart TD
 P1[PHP workers app A] --> G[Bounded Pooler]
 P2[PHP workers app B] --> G
 G --> C1[DB connection 1]
 G --> C2[DB connection 2]
 C1 --> D[(PostgreSQL)]
 C2 --> D

অনেক application client connection pooler-এ আসে। Pooler সীমিত server connection database-এ দেয়। Client count আর backend count তাই আলাদা metric। তবে long transaction একটি server connection বেশি সময় ধরে রাখে। Saturation হলে queueing latency বাড়ে, তাই pool wait-এর deadline এবং application timeout একসঙ্গে পরিকল্পনা করুন।

PHP ও Laravel-এ প্রয়োগ

নিচের action fragment transaction ছোট রাখার উদাহরণ। Order model, authorized user ID এবং validated order ID ধরা হয়েছে। Network call transaction-এর বাইরে। Pool endpoint ও PDO options config/database.php-এ deployment অনুযায়ী configure করতে হবে; fragment নিজে pooler install করে না।

use App\Models\Order;
use Illuminate\Support\Facades\DB;

$order = DB::transaction(function () use ($orderId, $userId) {
    $order = Order::query()
        ->where('user_id', $userId)
        ->lockForUpdate()
        ->findOrFail($orderId);
    $order->update(['status' => 'processing']);
    return $order;
});
// External HTTP calls happen outside this transaction.

সুবিধা, সীমাবদ্ধতা ও trade-off

Pooling handshake ও backend process cost কমাতে পারে, কিন্তু wait queue ও compatibility যোগ করে। Pool size বড় করলে throughput সবসময় বাড়ে না; database CPU, disk ও lock contention বাড়তে পারে। ছোট pool overload থেকে কিছুটা রক্ষা করে, তবে queue wait user latency বাড়ায়। Target concurrency load test করে নির্ধারণ করুন; অন্য system-এর pool size অন্ধভাবে copy করবেন না।

সাধারণ ভুল

App workers × replicas connection budget হিসাব না করা।
Transaction-এর ভিতর ধীর HTTP call রাখা।
Transaction pooler-এ session state স্থায়ী ধরে নেওয়া।

আরও একটু গভীরে

Budget-এ web worker, queue worker, scheduler, migration ও admin connections ধরুন। PostgreSQL reserved capacity operations-এর জন্য রাখা দরকার। PgBouncer version/config অনুযায়ী prepared statements-এর support ভিন্ন হতে পারে; driver mode ও pool mode primary docs দেখে পরীক্ষা করুন। Persistent PDO connection per-process reuse দিতে পারে, cross-process shared pool নয়। Connection leak, idle-in-transaction এবং transaction age monitoring করুন।

মনে রাখুন

Pool database capacity-এর সামনে bounded gate। Borrowing time ও transaction duration কমান। App scaling-এর আগে মোট client ও backend connection demand হিসাব করুন।

নিজে চেষ্টা করুন

ধরুন ছয় app replica, প্রতিটিতে দশ web worker ও চার queue worker। Potential DB demand হিসাব করুন। তারপর দুই migration/admin reserve group ও deploy overlap যোগ করুন। Staging-এ pool full হলে request timeout ও recovery পরীক্ষা করুন।

নিজের বোঝা যাচাই করুন

1. Laravel facade মানেই shared pool?

না। PHP process lifecycle ও configured driver অনুযায়ী connection থাকে। আলাদা process সাধারণত নিজস্ব connection তৈরি করতে পারে।

2. Pool বড় করলে লাভ?

শুধু database unused capacity থাকলে হতে পারে। Saturated database-এ concurrency বাড়িয়ে contention ও latency আরও বাড়তে পারে।

3. Transaction pooling-এর ঝুঁকি?

পরের transaction অন্য server connection পেতে পারে। Session variables, temporary state ও protocol compatibility পরীক্ষা করতে হবে।

4. HTTP call transaction-এর বাইরে কেন?

Network অপেক্ষায় lock ও connection ধরে রাখা কমে। তবে DB state ও external side effect-এর consistency workflow আলাদা design করতে হয়।

5. কোন metric জরুরি?

Active/idle connections, wait time, transaction age, timeout ও database saturation। শুধু connection count দেখলে কাজের duration বোঝা যায় না।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।