Performance Profiling: bottleneck ও tail latency

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

• Measurement দিয়ে bottleneck আলাদা করা
• N+1 এবং slow query ধরতে পারা
• Tail latency ও instrumentation overhead বোঝা

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

Product page ধীর, তাই team আরও web server কিনলেন। সমস্যা আসলে প্রতিটি product-এর category আলাদা query-তে পড়া; traffic বাড়তেই database connection শেষ। Performance optimization অনুমান দিয়ে resource বাড়ানো নয়। Representative workload-এ সময় কোথায় ব্যয় হচ্ছে মেপে একটি bottleneck বদলান, তারপর একই measurement দিয়ে ফল যাচাই করুন।

সহজ করে বুঝি

Profiling execution-এর CPU, memory, I/O ও waiting time প্রকাশ করে। Bottleneck overall throughput বা latency সীমিত করে এমন constrained part। Average latency দ্রুত requests-এর আড়ালে slow tail লুকায়; p95/p99 ও distribution দেখুন। N+1 pattern collection-এর প্রতিটি row-এর জন্য নতুন query করে। Eager loading কিছু query কমায়, তবে unbounded relationship loading memory বাড়াতে পারে।

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

একটি restaurant-এ waiter বাড়িয়েও লাভ নেই যদি একটিমাত্র oven সব order আটকে রাখে। Queue কোথায় জমছে বুঝে oven, recipe বা scheduling বদলাতে হয়। একটি ধাপ দ্রুত করলে পরের ধাপ bottleneck হতে পারে।

নকশাটি দেখুন

flowchart LR
 W[Representative workload] --> M[Measure latency and resources]
 M --> B[Find dominant wait or work]
 B --> C[Change one bottleneck]
 C --> V[Compare same workload]
 V --> R[Check correctness and regressions]

Workload থেকে baseline নিন। Trace, query count ও resource metrics দিয়ে bottleneck hypothesis বানান। এক পরিবর্তনের পরে একই traffic/data pattern-এ compare করুন। শুধু latency নয় memory, error ও correctness দেখুন। Cache hit দিয়ে synthetic result ভালো হলেও cold cache এবং large tenant behavior আলাদা থাকতে পারে। কোনো সংখ্যাকে universal benchmark হিসেবে ব্যবহার করবেন না।

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

AppServiceProvider::boot method-এর fragment। QueryExecuted event থেকে duration দেখা হয়েছে; SQL bindings sensitive হতে পারে বলে log করা হয়নি। Threshold illustrative diagnostic setting, production SLO নয়। Logging overhead ও event volume বিবেচনা করে sampling এবং retention যোগ করুন।

use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;
DB::listen(function (QueryExecuted $query) {
    if ($query->time > 200) {
        Log::warning('slow_database_query', [
            'duration_ms' => $query->time,
            'connection' => $query->connectionName,
        ]);
    }
});

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

Index query দ্রুত করতে পারে কিন্তু writes ও storage cost বাড়ায়। Cache repeated read কমায় কিন্তু invalidation ও stale data risk আনে। Eager load query কমিয়ে response memory বাড়াতে পারে। Profiler এবং verbose logging নিজেও workload বদলায়। Production-safe sampling দিয়ে hypothesis ধরুন, controlled environment-এ detail পরীক্ষা করুন এবং real workload-এ cautiously verify করুন।

সাধারণ ভুল

• Measure না করেই micro-optimization করা।
• একটি query দ্রুত দেখে total endpoint দ্রুত দাবি করা।
• Production SQL bindings নির্বিচারে log করা।

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

Tail latency fan-out-এ বাড়ে: অনেক dependency-র মধ্যে একটি slow হলেও overall response অপেক্ষা করে। Queueing saturation-এর কাছে nonlinearly বাড়তে পারে, তাই CPU average কম হলেও lock contention বা I/O saturation থাকতে পারে। Query plan-এ actual row estimate mismatch, missing index ও unnecessary sort দেখুন। Optimization-এর পরে concurrency correctness এবং transaction isolation অপরিবর্তিতভাবে কাজ করছে কি না যাচাই করুন।

মনে রাখুন

প্রথমে representative measurement, তারপর bottleneck hypothesis, এক পরিবর্তন এবং correctnessসহ পুনরায় যাচাই।

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

Product list-এর query count ও latency baseline নিন। Category eager loading-এর পরে query count, response memory ও latency তুলনা করুন। Small এবং large tenant data আলাদা ব্যবহার করে trade-off লিখুন।

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

1. আরও server সবসময় সাহায্য করে?

Shared database বা lock bottleneck হলে নয়। Web concurrency বাড়িয়ে চাপ আরও বাড়াতে পারে।

2. N+1 কী?

এক parent query-এর পরে প্রতিটি item-এর জন্য repeated relationship query। Eager loading ও query design দিয়ে কমানো যায়।

3. p99 কেন?

Slow tail-এ কিছু user-এর খারাপ অভিজ্ঞতা দেখায়। পর্যাপ্ত sample ও consistent window দরকার।

4. Profiler free?

না। CPU, memory ও I/O overhead থাকতে পারে। Sampling ও environment selection জরুরি।

5. Optimization complete কখন?

একই representative workload-এ gain, correctness এবং নতুন regression যাচাইয়ের পরে। Bottleneck স্থানান্তর হতে পারে।

আরও পড়ুন

• Laravel query events
• PostgreSQL EXPLAIN