‏سیستمت کند نیست؛ گلوگاهت بهینه نیست

نویسنده می‌گه روی یه پروژهٔ ETL نسبتاً بزرگ کار کرده با حدود ۳۰۰ میلیارد ردیف تو یه جدول و تقریباً ۶ ترابایت دیتای فشرده، که با لاراول ساخته و به چالش‌های تازه‌ای خورده: اشباع دیسک، محدودیت شاردهای ElastiCache، جدول‌های خیلی بزرگ و بیشتر. به گفتهٔ نویسنده بیشتر این مشکل‌ها قبل از production سخت قابل‌تست و پیش‌بینی‌ان، پس آپدیتت رو deploy می‌کنی و بعد می‌بینی سیستم می‌خوابه؛ و می‌گه خودش حدود صد بار این کارو کرده.

اول تعریف می‌کنه گلوگاه چیه: هر بخشی از سیستم که از بقیه کندتره و backlog می‌سازه؛ می‌تونه insertهای دیتابیس، اشباع I/O دیسک، محدودیت CPU یا محدودیت یه API خارجی باشه. می‌گه اولین حرکت باید بهینه کردن یا رفع خود گلوگاه باشه، ولی گاهی به «حد معقول» می‌رسی؛ مثلاً می‌شه با ۵٬۰۰۰ دلار در ماه فقط ۱٪ بهبود گرفت که برای همه معاملهٔ منطقی نیست، یا گلوگاه کاملاً خارج از کنترلته مثل rate limit یه API.

نکته‌ای که نویسنده می‌گه بیشتر می‌سوزونه اینه: بهینه کردن قسمت اشتباه مشکل رو حل نمی‌کنه. چند بار بخش‌هایی از سیستم رو بهینه کرده و بعد فهمیده اون بهینه‌سازی درخشان اصلاً سرعت کل سیستم رو بهتر نکرده، چون گلوگاه هنوز گلوگاه بوده. تشبیهش یه بزرگراهه: از ۴ بانده به ۸ بانده ارتقاش دادی که ماشین‌ها سریع‌تر برن، ولی مشکل واقعی رمپ خروجی بود، پس هیچ بهبود معناداری نگرفتی. وقتی این اتفاق می‌افته یعنی قسمت درست سیستم رو اندازه نمی‌گیری و کورکورانه پرواز می‌کنی. برای همین نویسنده یه داشبورد Grafana برای CPU و حافظه و دیسک ساخته و با پکیج Prometheus اسپیتی متریک‌های اپ‌محور (تعداد و نوع و اندازهٔ فایل‌ها) رو ردیابی کرده؛ همین بهش نشون داد افت throughput فقط به‌خاطر بزرگ‌تر بودن فایل‌ها بوده، نه چیزی که نیاز به بهینه‌سازی داشته باشه.

بعد چند راهکار عملی می‌ده. اول، گلوگاه رو مشغول و در بهترین شرایط نگه دار: مثلاً برای یه API با سقف ۶۰ درخواست در دقیقه، ۶۰۰ درخواست رو با صف لاراول به پس‌زمینه می‌فرستی و دقیقاً ۶۰ (یا محتاطانه ۵۵) تا در دقیقه می‌فرستی. دوم، مراحل رو decouple کن تا throughput صاف بشه: نویسنده می‌گه اولش یه job واحد رکوردها رو استخراج و مستقیم درج می‌کرد، ولی چون فایل‌های مختلف دیتابیس رو با سرعت‌های متفاوت پر می‌کردن، این کارو به دو job جدا کرد؛ اولی رکوردها رو به یه فایل CSV می‌نویسه و دومی اون CSV رو import می‌کنه. این اجازه داد استخراج تهاجمی و موازی اجرا بشه بدون اینکه دیتابیس رو خفه کنه، و importها رو ثابت در بیشترین throughput نگه داشت. اسم این کارو می‌ذاره «بهینه کردن به سمت گلوگاه، نه دورش».

در آخر دربارهٔ اینکه کِی بهینه کنی و کِی فقط منابع بیشتر بریزی حرف می‌زنه و می‌گه این یه پاندوله که عقب‌جلو می‌ره: اولش ارتقای سرور از ۵ به ۱۵ دلار در ماه ساده‌ست، ولی وقتی ۱۵ دلار به ۱٬۵۰۰ و بعد ۳٬۰۰۰ دلار می‌رسه، یه هفته وقت گذاشتن روی بهینه‌سازی معنا پیدا می‌کنه. توصیهٔ نهاییش اینه که قهرمان‌بازی درنیار؛ لازم نیست هر بار ۵۰٪ سود بگیری، ۱۰٪ اول بعد ۵٪ بعدی، تا بدون over-engineer کردن به حد معقول برسی. همیشه throughput رو قبل و بعد اندازه بگیر تا مطمئن شی بهینه‌سازی واقعاً کار کرده و پیچیدگی الکی و بدهی فنی اضافه نکرده.

نکات کلیدی:

• بهینه کردن قسمت اشتباه بی‌فایده‌ست اگه گلوگاه هنوز گلوگاه باشه
• بدون مانیتورینگ درست (Grafana، Prometheus) کورکورانه پرواز می‌کنی
• صف برای رعایت rate limit و مشغول نگه داشتن گلوگاه در بهترین حالت عالیه
• decouple کردن مراحل به چند job، throughput رو صاف و قابل‌پیش‌بینی می‌کنه
• بهبود تدریجی (۱۰٪ بعد ۵٪) بهتر از دنبال سود بزرگ و over-engineering ئه