وقتی منابع کافی دارید، ولی همچنان اپ کند است!
همه‌چی طبق انتظار پیش رفته. CPU خالیه، RAM هنوز نصفش پر نشده، دیسک سالمه و لاگ‌ها هم که آروم و بی‌سروصدا. ولی اپلیکیشن کُنده. نه خطایی هست، نه پیامی درباره مشکل، نه حتی نشونه‌ای از فشار. فقط یه حس آزاردهنده: «همه‌چی کند شده!»
اگر این تجربه رو داشتی، بدون که تنها نیستی. این مقاله درباره همون لحظاتی‌ست که منابع هست، ولی سرعت نیست.
توهم آرامش در اعداد
وقتی همه متریک‌ها خوب به‌نظر میان، طبیعیه که احساس کنیم سیستم مشکلی نداره. ولی واقعیت اینه که منابع کافی همیشه به معنی عملکرد مناسب نیست. خیلی از گلوگاه‌ها، به‌خصوص در اپ‌های پیچیده، خودشون رو در قالب مصرف CPU یا RAM نشون نمی‌دن. بعضی‌ها توی تاریکی کار خودشون رو می‌کنن.
گلوگاه‌های نامرئی کجاها قایم می‌شن؟
۱. عملیات I/O که منتظر می‌مونن
فرض کن یه فایل باید از دیسک خونده شه یا API خارجی قراره پاسخش رو بده. CPU بیکار نشسته تا اون تموم شه. از بیرون همه‌چی آرومه، ولی اپلیکیشن منتظره. و این انتظار، خودش کندی می‌سازه.
۲. sync وسط async
برنامه‌ت پر از فانکشن‌های async و صف‌های هم‌زمانه. اما یه فانکشن sync کوچیک وسطش باعث می‌شه همه منتظر اون بمونن. انگار توی بزرگراه، یه ماشین ناگهانی ایستاده.
۳. کانکشن‌هایی که به ته می‌رسن
وقتی درخواست‌ها بیشتر از ظرفیت connection pool بشن، بقیه باید صبر کنن. مثل رستورانی با ۵ میز، وقتی ۱۰ نفر هم‌زمان بیان، پنج‌تای دیگه باید بیرون منتظر بمونن، حتی اگه غذا و گارسون به‌اندازه کافی هست!
۴. threadهایی که تو صف گیر می‌افتن
شاید حتی یه بخش ساده از کد باعث بشه thread اصلی منتظر یه پردازش فرعی بمونه. اینجور گلوگاه‌ها مثل ترافیک در یک کوچه فرعی هستن، اما کل شهر رو قفل می‌کنن.
۵. taskهایی که ترتیبشون اپ رو می‌کشه
وقتی taskهایی با اولویت پایین جلوی taskهای مهم صف می‌کشن، نتیجه یه حس کلی از کندیه، در حالی که هیچ چیز «خراب» نیست.
کندی بدون صدا مصداق‌های واقعی اما پنهان
لود کند صفحه گزارش، به‌خاطر queryهایی با join زیاد
کندی هنگام لاگین فقط در ساعات اوج (مثلاً وقتی چند کاربر هم‌زمان وارد می‌شن)
صفحات admin با دیتاهای زیاد که ناگهان فریز می‌شن، بدون خطا
آپلود فایل که کند پیش می‌ره، در حالی که پهنای باند پر نیست
چک‌لیست سریع آیا سیستم تو هم همین شکلیه؟
کاربرها از کندی می‌گن ولی سرورها بیکارن؟
هیچ خطایی ثبت نمی‌شه ولی رضایت کاربر پایینه؟
taskهایی داری که فقط در ساعات خاصی کند می‌شن؟
از connection pool استفاده می‌کنی ولی بعضی درخواست‌ها دیر جواب می‌گیرن؟
فانکشن‌های async به اندازه انتظار سریع نیستن؟
و حالا یک تجربه واقعی از یک اپ فروشگاهی
یه فروشگاه آنلاین داشتیم که در زمان خاصی (مثلاً پنج‌شنبه‌شب‌ها) به شدت کند می‌شد. اما هیچ‌کدوم از لاگ‌ها یا مانیتورها چیز عجیبی نشون نمی‌دادن. بعد از بررسی عمیق متوجه شدیم که سیستم تخفیف به ازای هر کاربر یه پردازش سنگین انجام می‌داد که هم sync بود، هم I/O داشت. همین یه مورد، باعث کندی سراسری می‌شد. تغییر اون فانکشن و استفاده از cache، مشکل رو کاملاً حل کرد.
اما وقتی زیرساخت به‌موقع هشدار می‌ده
توی یکی از پروژه‌ها، مانیتورینگ برنت نشون داد که تعداد اتصال‌های باز به دیتابیس به‌شکل غیرعادی ثابته. بررسی بیشتر نشون داد یه فانکشن async توی backend یک کانکشن رو نمی‌بست. این موضوع هیچ خطایی ایجاد نکرده بود، اما کندی شدید باعث نارضایتی کاربران شده بود. پیدا کردن مشکل، به لطف logهای دقیق و مانیتورینگ، در کمتر از یک روز انجام شد.
چرا پیدا کردن این گلوگاه‌ها این‌قدر سخته؟
چون ابزارهای رایج توسعه‌دهنده معمولاً برای خطا طراحی شدن، نه «کندی بی‌خطا». خیلی از bottleneckها توی ابزارهایی مثل Task Manager یا htop ظاهر نمی‌شن. اون‌ها در سطح معماری، ترتیب اجرا یا syncهای پنهان اتفاق می‌افتن.
زیرساخت خوب، فقط منابع نیست
داشتن CPU بالا یا رم بیشتر همیشه راه‌حل نیست. زیرساختی خوبه که ابزار تحلیل رفتار واقعی اپلیکیشن رو هم در اختیارت بذاره. جایی که بفهمی چه چیزی، کِی و کجا باعث کندی شده.
حالا راهکار برنت چیه؟
بریم ببینیم…
۱. آشکار کردن گلوگاه‌های نامرئی با مانیتورینگ زنده
بسیاری از کندی‌ها به خاطر bottleneckهایی هستن که در ظاهر منابع رو نمی‌گیرن، ولی رفتار سیستم رو قفل می‌کنن. برنت، با ابزارهای مانیتورینگ بلادرنگ، کمک می‌کنه بتونی روند اجرای درخواست‌ها، مصرف I/O و صف‌های اتصال رو ببینی—همون‌هایی که معمولاً از چشمت دور می‌مونن.
۲. فراهم‌کردن فضای ایزوله برای تست رفتار کندی
وقتی در محیط واقعی تغییر ایجاد کنی، خطر داری. ولی با محیط‌های staging در برنت، می‌تونی رفتار اپلیکیشن رو در شرایط مختلف شبیه‌سازی و تست کنی—مثلاً بررسی تاثیر یک عملیات sync وسط async، یا تأخیر در APIهای خارجی.
۳. تحلیل الگوهای اتصال و صف‌ها
کندی ناشی از connection poolهایی که درست مدیریت نمی‌شن، با نگاه سطحی به logها مشخص نمی‌شه. برنت این امکان رو می‌ده که اتصال‌های هم‌زمان، taskهای معلق و صف‌های پر رو با ابزار مناسب ببینی.
۴. ثبت و بررسی کندی‌هایی که خطا نیستن
کندی‌هایی که باعث نارضایتی کاربر می‌شن، ولی هیچ خطایی تو لاگ نیست؟ برنت با لاگ مرکزی و قابلیت تحلیل زمان اجرای درخواست‌ها کمک می‌کنه اون لحظات رو از زیر دست در ندی.
۵. درک بهتر از «کی کند می‌شه؟ کجا کند می‌شه؟»
در یک زیرساخت معمولی، شاید فقط بفهمی که اپ کند شده. ولی برنت کمک می‌کنه بدونی دقیقاً کِی، کجا و در چه زمینه‌ای کند شده بدون حدس و گمان.
محیط ایزوله برای تست کندی؟ بله، معلومه که لازمه!
قبل از اینکه همه‌چی بره روی production، خوبه این رفتارها رو تو محیط staging شبیه‌سازی کنی. مثلاً:
اجرای هم‌زمان چند task با منابع زیاد
بررسی رفتار async و sync در کنار هم
تحلیل صف‌ها تحت بار بالا
حالا که برنت این بستر رو داره پس تست بدون ریسک = پیشگیری از فاجعه دیگه چی از این بهتر؟
کندی بدون دلیل، فقط بدون ابزار دیده نمی‌شه اینکه منابع هست ولی اپ کند شده، خودش یک نشونه‌ست. نشونه‌ای از گلوگاه‌هایی که دیده نمی‌شن ولی تجربه کاربر رو نابود می‌کنن. با ابزار مناسب، تست هوشمند، و زیرساختی که دید شفاف بهت بده، می‌شه حتی نامرئی‌ترین کندی‌ها رو هم پیدا و رفع کرد.
برنت این دید رو بهت می‌ده. تا قبل از اینکه کاربر اعتراض کنه، خودت بفهمی کجای مسیر داره گیر می‌کنه.
