ارائه Critical Path Analysis: تکنیکی از پروژه منهتن برای دیباگ Latency در Go!

یکی از ارائه های جذاب GopherCon 2025 ارائه Felix Geisendörfer از Datadog بود درباره پروفایلینگ request latency با استفاده از Critical Path Analysis.

این تکنیک جالبه چون اصلاً برای نرم‌افزار طراحی نشده بود. از پروژه منهتن میاد! همون پروژه‌ای که بمب اتمی ساخت. ایده‌ش ساده‌ست: وقتی یه پروژه بزرگ داری با زیرپروژه‌های موازی، کدوم مسیر واقعاً تعیین‌کننده زمان کله؟

حالا Felix این رو آورده روی Go و goroutine ها.

مشکلی که حل می‌کنه اینه که پروفایلینگ سنتی بهت میگه mutex contention داری، ولی نمیگه این چقدر روی latency کاربر تأثیر گذاشته. مثلاً یه پروفایل نشون میده ۴۳۹ ثانیه contention تو ۶۰ ثانیه داشتی. خب این خیلی بده، ولی سوال اصلی اینه: کدوم بخشش واقعاً روی request های کاربر تأثیر گذاشته؟

اینجاست که execution tracer میاد وسط. برخلاف CPU profiling که فقط on-CPU رو نشون میده، execution tracer همه state transition ها رو ثبت می‌کنه: کی goroutine داشت run می‌شد، کی منتظر mutex بود، کی منتظر channel بود، کی scheduling latency داشت. یه تصویر کامل از زندگی goroutine هات.

راه‌حل اینه که از آخر request بری عقب و ببینی کدوم goroutine ها واقعاً سر راه بودن. اگه G1 منتظر G2 و G3 باشه و G3 دیرتر تموم بشه، سریع‌تر کردن G2 هیچ فایده‌ای نداره. این همون critical path هست.

یه کار خفن دیگه که تیم Datadog کرده اینه که overhead اجرای execution tracer رو از ۱۰-۲۰ درصد به ۱-۲ درصد رسوندن. یعنی الان میشه تو production ازش استفاده کرد.

این ارائه خیلی ارزشمنده چون نشون میده پروفایلینگ می‌تونه خیلی دقیق‌تر از چیزی باشه که عادت کردیم. به جای اینکه بگیم mutex contention داریم، بیاید همه جا رو optimize کنیم، می‌تونیم دقیقاً بفهمیم کجا واقعاً مهمه.

آقای Felix امیدواره این کار رو open source کنه.

اگه با Go کار می‌کنید و tail latency براتون مهمه، پیشنهاد می‌کنم این ارائه رو ببینید.

https://www.youtube.com/watch?v=BayZ3k-QkFw

@gocasts