زمان مطالعه: ۵ دقیقه
مخاطب: توسعه‌دهندگان، تیم‌های فنی، مدیران زیرساخت و محصول
خلاصه مقاله
وقتی اپلیکیشن کند می‌شه، اولین چیزی که به ذهن تیم فنی می‌رسه دیتابیسه. اما همیشه این‌طور نیست. گاهی دیتابیس بدون مشکل کار می‌کنه، اما کاربران هنوز کندی حس می‌کنن. این مقاله بررسی می‌کنه که چه گلوگاه‌هایی به‌جز دیتابیس می‌تونن باعث کندی باشن، چطور تشخیصشون بدیم و چه راهکاری برای تحلیل حرفه‌ای‌تر داریم.
سناریویی که برای همه آشناست
کاربر می‌گه: «صفحه دیر باز می‌شه.» مدیر پروژه می‌پرسه: «دیتابیس رو چک کردید؟» ولی همه چیز روی DB نرماله. پس مشکل از کجاست؟ در اکثر مواقع، دیتابیس اولین متهمه. ولی وقتی queryها سریع اجرا می‌شن، مصرف منابع پایینه، و لاگ اروری هم نیست، باید دنبال جواب جای دیگه گشت.
همیشه تقصیر رو گردن دیتابیس انداختن!
مثل این می‌مونه که چون ماشین حرکت نمی‌کنه، فرض کنیم فقط بنزین تموم شده در حالی که شاید ترمز قفل کرده باشه، یا تسمه پاره شده باشه. دید نقطه‌ای نسبت به یک سیستم چندلایه مثل اپلیکیشن، باعث می‌شه گلوگاه‌های واقعی رو نبینیم.
کندی ممکنه از این بخش‌ها باشه، نه دیتابیس:
- اتصال کند به API خارجی درخواست تا پایان پاسخ منتظره می‌مونه و همه چیز قفل می‌شه
- عملیات سنگین روی فایل یا I/O مصرف منابع پایین می‌مونه ولی سرعت پاسخ افت می‌کنه
- صف‌های async یا task queueها اگر یکی از taskها قفل بشه، همه چیز معطل می‌مونه
- poolهای اتصال پر یا ناکارآمد بعضی درخواست‌ها منتظر آزاد شدن connection می‌مونن
- فانکشن‌های sync وسط ساختار async حتی یک خط sync ممکنه کل system رو قفل کنه
- caching ناکارآمد هر بار درخواست مستقیم به منبع اصلی (مثلاً DB) می‌ره
تقصیر دیتابیس نبود!
در یک پروژه فروشگاهی، لاگ‌ها نشون می‌داد DB کمتر از ۱۰٪ بار داره، ولی کاربران در ساعات اوج دچار کندی شدید بودن. بررسی‌ها نشون داد که سرویس ارسال پیامک (API ثالث) در شرایط پیک، delay زیادی داشت. اما چون این مرحله در endpoint پرداخت قرار داشت، کل فرآیند کند می‌شد. دیتابیس بی‌تقصیر بود.
بهتره قبل از مقصر دانستن دیتابیس این‌ها رو بررسی کنید:
- آیا responseهای API خارجی کند یا متغیر هستن؟
- آیا صف‌های async یا job queue داری؟
- آیا connection pool به حداکثر رسیده؟
- آیا caching مناسبی داری؟
- آیا همه کدهای شما واقعاً async هستن یا یک sync داخلش مخفی شده؟
- آیا لاگ دقیقی از مدت زمان اجرای هر مرحله داری؟
چطور بفهمیم مشکل دقیقاً کجاست؟
زیرساخت‌هایی مثل برنت کمک می‌کنن که تحلیل رفتار اپ فراتر از دیتابیس باشه مثل دیدن bottleneckهای دقیق در مسیر درخواست با APM داخلی، مشاهده صف‌های async یا taskهایی که گیر افتادن، بررسی تاخیر در APIها، I/O، و middlewareها همچنین مانیتور لحظه‌ای منابع بدون نیاز به حدس و آزمون‌و‌خطا.
تیمی که فقط DB رو بررسی می‌کنه، همیشه دنبال مشکل می‌گرده؛ تیمی که دید کامل داره، به جواب می‌رسه در اصل مشکل همیشه همون‌جایی نیست که فکر می‌کنی...
اپلیکیشن مثل یک ماشین چندبخشه. دیتابیس یکی از اجزای مهمشه، ولی نه تنهاش. برای پیدا کردن دلیل واقعی کندی، باید ساختار کامل سیستم رو دید، ابزار درستی داشت، و تحلیل داده محور انجام داد نه تحلیل بر پایه حدس و تجربه قبلی. تحلیل حرفه‌ای یعنی به دیتابیس شک کن، ولی قبل از متهم‌کردنش، بررسی کن واقعاً مقصره یا نه.
