قبل از Optimize اندازه بگیر؛ کندی را با Profile پیدا کن نه حدس
برنامه کند است و تیم بر اساس حدس query، framework یا زبان را مقصر میداند و refactor پرهزینه شروع میکند.
زمان پاسخ را بخشبندی کن، مسیر کند را profile کن و فقط جایی را بهینه کن که سهم واقعی در تأخیر دارد.
چطور دقیقتر به موضوع نگاه کنیم؟
- یک سناریوی کند مشخص و قابل اندازهگیری انتخاب کن.
- زمان end-to-end و سپس بخشهای اصلی مثل DB، API خارجی و render را جدا ثبت کن.
- با profiler یا tracing نقطهای را پیدا کن که واقعاً بیشترین زمان یا منابع را مصرف میکند.
- یک تغییر کوچک انجام بده و قبل/بعد را با همان سناریو اندازه بگیر؛ اگر اثر ندارد، پیچیدگی را نگه ندار.
چرا این موضوع مهم است؟
گلوگاه واقعی ممکن است شبکه، I/O، query، serialization یا یک loop کوچک باشد. بهینهسازی حدسی میتواند پیچیدگی را زیاد و اثر ناچیز ایجاد کند.
سؤالهایی که معمولاً بعدش پیش میآید
کد تمیزتر همیشه سریعتر است؟
نه؛ خوانایی و performance اهداف مرتبط ولی یکسان نیستند و باید اندازهگیری شود.
از cache شروع کنم؟
فقط اگر داده نشان میدهد محاسبه یا I/O تکراری گلوگاه است و invalidation را میتوانی درست مدیریت کنی.