منابع داری، ولی اپلیکیشنت هنوز کُنده؟

۵ گلوگاه نامرئی که تجربه کاربر رو نابود می‌کنن...
 زمان مطالعه: حدود ۷ دقیقه
خلاصه مقاله

•  وقتی CPU و RAM آزادن ولی اپ کند شده، معمولاً گلوگاه‌های نامرئی مقصرن
•  این گلوگاه‌ها مثل connection pool پر، sync وسط async یا صف‌های بی‌پاسخ دیده نمی‌شن
•  ابزارهای رایج مثل لاگ یا Task Manager نشونشون نمی‌دن
•  تجربه کاربری افت می‌کنه ولی اروری ثبت نمی‌شه
•  این مقاله با مثال‌های واقعی نشون می‌ده چطور این گلوگاه‌ها رو کشف و کنترل کنیم

سکوتی که دردسرسازه

همه‌چی طبق انتظار پیش می‌ره. CPU کمتر از ۳۰٪، RAM نیمه‌پر، لاگ‌ها آروم. ولی کاربرها می‌گن: «کند شده». نه اروری هست، نه مصرف غیرعادی. فقط یه حس آزاردهنده: «هیچی سریع نیست.»
این مقاله درباره همین سکوت نگران‌کننده‌ست. کندی‌هایی که ابزارها نمی‌فهمن، ولی کاربر حسش می‌کنه.
تفکر اشتباه: «اگه خطایی نیست، پس همه‌چی خوبه»
خیلی از تیم‌ها فکر می‌کنن وقتی لاگ ارور نداریم و مانیتورینگ سبزه، مشکلی وجود نداره. ولی واقعیت اینه که بیشتر گلوگاه‌های مهم، ارور نمی‌دن فقط همه‌چیز رو کند می‌کنن.

۵ گلوگاه نامرئی که عملکرد واقعی اپ رو می‌کشن:

•  عملیات I/O معطل: دیتا منتظره از API بیاد یا فایلی از دیسک خونده بشه. CPU بی‌کار نشسته، ولی کاربر حس انتظار داره.
•  یک فانکشن sync در دل async: مثل ماشین توقف کرده وسط بزرگراه. همه چی قفل می‌شه، چون یک تابع بی‌خبر sync نوشته شده.
•  connection pool پره ولی دیتابیس بیکاره: درخواست‌ها پشت در منتظرن چون ظرفیت اتصال تموم شده. سرور قویه، ولی راه ورود بسته‌ست.
•  صف threadهایی که دیده نمی‌شن: یه thread فرعی باعث قفل‌شدن پردازش اصلی می‌شه. منابع آزادن، ولی اجرا متوقفه.
•  ترتیب اجرای task اشتباهه: وظایف کم‌اهمیت جلوی حیاتی‌ها صف کشیدن. نتیجه؟ تجربه کاربری کند ولی بی‌خطا.

آیا سیستم تو هم این نشونه‌ها رو داره؟

•  منابع خالیه ولی کاربران شاکی‌ان؟
•  صفحات فقط بعضی وقتا کند می‌شن؟
•  از connection pool استفاده می‌کنی ولی بعضی درخواست‌ها دیر میان؟
•  هیچ خطایی تو لاگ نیست، ولی تجربه خوب نیست؟

تجربه ۱: تخفیفِ کندکننده
در یک فروشگاه آنلاین، سیستم تخفیف برای هر کاربر یه پردازش sync و I/O سنگین انجام می‌داد. پنج‌شنبه شب‌ها اپ کند می‌شد. لاگ‌ها چیزی نمی‌گفتن. با caching ساده، همه‌چی حل شد.
تجربه۲: کانکشنی که بسته نمی‌شد
در یکی از پروژه‌ها، مانیتورینگ برنت نشون داد تعداد connectionهای باز ثابته. لاگ اروری نداشتیم. بررسی نشون داد یه async function کانکشن رو نمی‌بست. بعد از fix، سرعت اپ برگشت.
چرا ابزارهای معمول این کندی‌ها رو نمی‌بینن؟
چون برای crash یا error طراحی شدن. نه برای تأخیر. این گلوگاه‌ها در ترتیب اجرا، صف‌ها یا معماری async پنهان می‌شن. نه توی htop و نه توی New Relic معمولی دیده می‌شن.

تست پیشنهادی برای شما

قبل از اینکه کاربر شکایتی کنه، این تست رو انجام بده:

•  چند کاربر هم‌زمان وارد پنل admin بشن
•  فرم‌های سنگین رو پر کنن
•  زمان پاسخ رو زیر نظر بگیر

 اگه تاخیر داری ولی CPU و RAM نرماله → bottleneck داری

راهکارهای زیرساختی برنت برای کشف این کندی‌ها:

مانیتورینگ لحظه‌ای: دید دقیق از روند اجرا، صف‌ها، اتصال‌ها و رفتار async واقعی اپلیکیشن
 محیط ایزوله برای تست قبل از فاجعه: قبل از اینکه تغییرت به production بره، async/sync و صف‌ها رو شبیه‌سازی کن
 بررسی اتصال‌های باز، taskهای منتظر، و صف‌های پنهان: برنت کمک می‌کنه صف‌هایی که هیچ‌جا ثبت نمی‌شن رو ببینی
 لاگ‌گیری رفتار واقعی، نه فقط خطاها: ببین چه درخواست‌هایی دیر تموم می‌شن، حتی اگه اروری نیست
 منابع کافی نیست، دید کافی لازمه!
داشتن RAM و CPU مهمه، ولی بدون ابزار مناسب، گلوگاه‌ها از دستت در می‌رن. کندی واقعی جایی رخ می‌ده که دیده نمی‌شه در asyncهای ناقص، صف‌های منتظر، و اجرای ناهماهنگ. برنت این دید رو بهت می‌ده، تا قبل از اینکه کاربر اعتراض کنه، خودت بفهمی کجای مسیر گیره.

شفافیت، کلید سرعت واقعیه. از ابزارهای درون‌ساختی برنت استفاده کن، تا بتونی حتی نامرئی‌ترین کندی‌ها رو ببینی و رفعشون کنی.