تمرکز این راهنما بر معماری v2 است
Pyroscope برای گردآوری و تحلیل پروفایل‌های اجرا به کار می‌رود. در معماری v2، Distributor داده ورودی را به Segment Writer هدایت می‌کند؛ داده در Object Storage قرار می‌گیرد و اطلاعات لازم برای یافتن آن در Metastore ثبت می‌شود. بخش پرس‌وجو با Query Frontend و Query Backend مسیر جداگانه‌ای دارد.
Metastore مؤلفه وضعیت‌دار اصلی این طراحی است و برای تکثیر از Raft استفاده می‌کند. Compaction Worker قطعه‌های کوچک را به بلوک‌های بزرگ‌تر ترکیب می‌کند. این مدل با معماری قدیمی Ingesterمحور v1 تفاوت دارد. مستند رسمی v1 توسعه فعال آن را پایان‌یافته می‌داند و برای استقرار تازه به v2 ارجاع می‌دهد.
پروفایل را با مسئله واقعی بخوانید
در تمرین پیشنهادی تحریریه، یک عملیات فرضی انتخاب کنید که هم بخشی محاسباتی و هم انتظار برای یک وابستگی دارد. بار و ورودی را ثابت نگه دارید و پیش و پس از یک تغییر کوچک، پروفایل و زمان پاسخ را ثبت کنید. هدف، مرتبط‌کردن تغییر کد با شواهد است؛ نه صرفاً تولید یک نمودار رنگی.
برای مقایسه، بازه زمانی، نوع پروفایل و نسخه برنامه را یکسان یا صریحاً ثبت کنید. نمودار مربوط به یک نمونه کم‌بار را با رخداد اوج مصرف نمونه دیگر مقایسه نکنید. یک نتیجه ظاهراً چشمگیر، بدون این زمینه می‌تواند برداشت اشتباه بسازد.
هزینه داده و پرس‌وجو
پیشنهاد ما شروع از برچسب‌های محدود مانند سرویس، محیط و نسخه انتشار است. پیش از افزودن شناسه‌های بسیار متنوع، ارزش آن‌ها را در پاسخ به پرسش عملی بسنجید. نگه‌داری داده‌ای که کسی روش استفاده از آن را نمی‌داند، فقط مسئله ظرفیت ایجاد می‌کند.
در آزمون زیرساخت، ورود پروفایل را ثابت نگه دارید و بار پرس‌وجو را افزایش دهید. نرخ خطا، زمان ثبت داده و تأخیر پاسخ را جدا مشاهده کنید. تفکیک معماری مسیرها دلیل حذف نیاز به این آزمون نیست؛ ظرفیت سرویس ذخیره‌سازی و محدودیت محیط همچنان اهمیت دارند.
مرز ادعا
این راهنما جای تعیین نرخ نمونه‌برداری برای همه برنامه‌ها نیست. هزینه جمع‌آوری و ارزش داده باید روی بار خودتان اندازه‌گیری شود. پیشنهاد تحریریه، تعریف یک پرسش مشخص پیش از نصب ابزار است؛ مثلاً «کدام بخش پس از انتشار جدید بیشتر CPU مصرف می‌کند؟» پاسخ به همین پرسش، از جمع‌آوری بی‌هدف همه داده‌های ممکن مفیدتر است.
نوع پروفایل را با پرسش انتخاب کنید
پروفایل CPU نشان می‌دهد نمونه‌های فعالیت پردازنده در چه مسیرهای فراخوانی دیده شده‌اند. این تصویر با زمان انتظار کاربر یکسان نیست؛ برنامه ممکن است بخش بزرگی از زمان پاسخ را منتظر شبکه یا دیسک باشد. پیش از تحلیل، بپرسید مسئله مصرف CPU است، تخصیص حافظه است یا انتظار و هم‌زمانی. انتخاب نوع داده نامرتبط می‌تواند نمودار زیبا بسازد اما پاسخ مسئله را ندهد. قابلیت‌های جمع‌آوری نیز به زبان، runtime و روش ابزارگذاری وابسته‌اند.
در یک مثال آموزشی، تابعی داده را تبدیل می‌کند و سپس از سرویس دیگری پاسخ می‌گیرد. اگر زمان کل زیاد شده ولی نمونه‌های CPU همان مقدار مانده‌اند، بهینه‌سازی حلقه محاسباتی لزوماً تأخیر اصلی را کم نمی‌کند. پروفایل را با trace و متریک زمان پاسخ کنار هم بخوانید. هر ابزار بخشی از داستان را نشان می‌دهد: trace مسیر درخواست را، متریک روند را و پروفایل سهم مسیرهای کد را. اتصال آن‌ها نیازمند زمان و هویت سرویس هماهنگ است.
خواندن flame graph بدون برداشت شتاب‌زده
پهنای یک بخش معمولاً به سهم مقدار اندازه‌گیری‌شده مربوط است و محور افقی را نباید مثل خط زمانی اجرای متوالی بخوانید. یک تابع پهن می‌تواند به خاطر فراخوانی فرزندانش سهم بزرگی داشته باشد. تفاوت هزینه خود تابع و هزینه تجمعی مسیر را بررسی کنید تا اشتباهاً تابع واسطه را منشأ همه مصرف ندانید. نام یک تابع نیز ممکن است بدون نمادهای مناسب مبهم باشد؛ کیفیت symbolها بخشی از کیفیت تحلیل است.
برای شروع، مسیرهای پهن را پیدا کنید و سپس سؤال مشخصی درباره آن‌ها بسازید. آیا این کار برای همه درخواست‌ها لازم است؟ آیا همان داده چند بار تبدیل می‌شود؟ آیا بخشی از محاسبه با اندازه ورودی رشد نامناسبی دارد؟ این پرسش‌ها باید به تغییر کوچک کد و آزمایش بعدی برسند. صرف حذف تابعی که در نمودار بزرگ دیده می‌شود ممکن است وظیفه ضروری برنامه را از بین ببرد یا هزینه را به جای دیگری منتقل کند.
مقایسه پیش و پس از انتشار
دو پروفایل را فقط زمانی مقایسه کنید که تفاوت زمینه آن‌ها روشن باشد. نرخ درخواست، ترکیب endpointها، اندازه ورودی و تعداد replica روی نتیجه اثر می‌گذارند. یک نسخه تازه ممکن است سهم نسبی تابعی را بیشتر نشان دهد چون بخش دیگری بهبود یافته است، نه چون همان تابع کندتر شده. مقدار مطلق، سهم نسبی و نتیجه کاربردی را کنار هم ببینید. بهبود واقعی باید در معیار مسئله نیز قابل مشاهده باشد.
برای تمرین، یک ورودی ثابت و یک بازه گرم‌کردن مشخص انتخاب کنید. نسخه اول را اجرا کنید، سپس تنها یک تغییر کد انجام دهید و آزمایش را با همان شرایط تکرار کنید. شناسه build را در برچسب یا یادداشت آزمایش نگه دارید. اگر هم‌زمان تعداد Pod و تنظیمات پایگاه داده را تغییر دهید، نسبت دادن نتیجه به کد دشوار می‌شود. این روش محدودیت آزمایش را آشکار می‌کند و از ادعای شتاب‌زده درباره درصد بهبود جلوگیری می‌کند.
مسیر نوشتن در معماری v2
در این معماری مسیر ورود داده و مسیر پرس‌وجو نقش‌های جدا دارند. برای عملیات، مهم است بدانید درخواست ورود در کدام مرحله پذیرفته شده و داده چه زمانی برای جست‌وجو قابل دسترس می‌شود. پاسخ موفق یک endpoint به تنهایی همه مراحل بعدی را ثابت نمی‌کند. یک پروفایل آزمایشی با برچسب مشخص بفرستید و زمان مشاهده آن را اندازه بگیرید. سپس همین آزمون را هنگام افزایش بار و پس از restart مؤلفه مربوط تکرار کنید.
ذخیره‌سازی Object یکی از وابستگی‌های مهم است. خطای مجوز، نام bucket اشتباه یا کندی سرویس ذخیره می‌تواند در بخشی دیگر به صورت تأخیر ورود یا جست‌وجو ظاهر شود. اعتبارنامه مسیر نوشتن و مسیر خواندن را با کمترین اختیار لازم طراحی کنید و روش چرخش آن‌ها را آزمایش کنید. داده محلی موقت را با داده پایدار اشتباه نگیرید. این تمایز هنگام تعویض گره یا بازیابی پس از خرابی تعیین‌کننده است.
Metastore و بازیابی اطلاعات جای‌گذاری
اطلاعاتی که نشان می‌دهد داده در کدام بخش ذخیره شده، برای پیدا کردن پروفایل‌ها حیاتی است. وجود Objectها بدون metadata قابل استفاده لزوماً تجربه جست‌وجوی سالم نمی‌سازد. درباره Metastore، روش تکثیر و بازیابی مستند همان نسخه را مبنا قرار دهید و آن را مانند یک مؤلفه بدون وضعیت حذف و بازسازی نکنید. مفهوم quorum باید به دامنه شکست واقعی و امکان ارتباط اعضا مرتبط شود.
آزمایش خرابی را ابتدا در محیط غیرتولیدی با داده قابل بازسازی انجام دهید. پس از توقف یک عضو، هم ورود داده جدید و هم جست‌وجوی داده قدیمی را بسنجید. سپس بازگشت عضو را بررسی کنید تا وضعیت آن با مجموعه هماهنگ شود. هدف صرفاً روشن شدن فرایند نیست؛ باید بتوان همان پروفایل شاهد را پیدا کرد. دستورالعمل بازیابی باید تفاوت خرابی یک عضو و از دست رفتن اکثریت یا داده پایدار را روشن کند.
Compaction و هزینه جست‌وجو
ورود پیوسته داده می‌تواند بخش‌های کوچک زیادی بسازد و ادغام آن‌ها برای رفتار بلندمدت ذخیره و جست‌وجو اهمیت دارد. عقب افتادن compaction ممکن است در ابتدا به شکل خرابی کامل دیده نشود، ولی هزینه خواندن یا تعداد اشیای ذخیره را تغییر دهد. وضعیت این مسیر را مستقل از تعداد درخواست موفق ورود پایش کنید. یک سامانه می‌تواند امروز داده بپذیرد و هم‌زمان بدهی عملیاتی برای روزهای بعد ایجاد کند.
پرس‌وجوی بسیار وسیع در زمان و برچسب‌ها نیز منابع بیشتری می‌خواهد. کاربر را تشویق کنید ابتدا سرویس، محیط و بازه حادثه را محدود کند. اگر پاسخ کند است، تفاوت میان جست‌وجوی انتخابی کوچک و جست‌وجوی همه سرویس‌ها را بررسی کنید. این آزمایش کمک می‌کند مسئله ظرفیت backend از پرس‌وجوی نامناسب جدا شود. سقف‌ها و محدودیت‌های عملی باید بر اساس بار خود سازمان تعیین شوند، نه بر مبنای تصور نامحدود بودن ذخیره‌سازی ابری.
برچسب‌ها و حساسیت اطلاعات
برچسب سرویس، محیط و نسخه برای مقایسه مفید است؛ شناسه هر درخواست یا هر کاربر می‌تواند تنوع بسیار زیادی بسازد. پیش از افزودن یک برچسب، یک پرسش تحلیلی مشخص تعریف کنید که بدون آن پاسخ داده نمی‌شود. داده با تنوع زیاد می‌تواند هزینه و پیچیدگی را بالا ببرد و گاهی اطلاعات شخصی را نیز وارد سامانه کند. برچسب‌گذاری باید قرارداد مشترک تیم‌ها داشته باشد تا یک سرویس با چند نام متفاوت در جست‌وجو پراکنده نشود.
نام توابع و مسیرهای کد نیز ممکن است اطلاعات داخلی را آشکار کنند. دسترسی به پروفایل‌ها را بر اساس نقش و محیط تنظیم کنید و نمونه‌های قابل اشتراک را بازبینی کنید. برای بررسی کارایی معمولاً نیازی به ثبت محتوای محرمانه ورودی نیست. اگر روش ابزارگذاری attribute اضافی می‌گیرد، دامنه آن را محدود نگه دارید. مشاهده‌پذیری مفید از ثبت هر داده ممکن به دست نمی‌آید؛ از ثبت داده‌ای حاصل می‌شود که پاسخ یک پرسش مشخص را ممکن می‌کند.
معیار پایان یک بهینه‌سازی
پس از تغییر، تنها کوچک شدن یک بخش نمودار را گزارش نکنید. زمان پاسخ، مصرف منبع و صحت نتیجه برنامه را نیز بررسی کنید. ممکن است کاهش CPU با افزایش حافظه یا تأخیر شروع همراه باشد و این مبادله برای محیط شما مناسب یا نامناسب باشد. نتیجه را با شرایط آزمایش و محدودیت آن بنویسید. پروفایل وسیله ساختن فرضیه و بررسی آن است و جای آزمون صحت رفتار برنامه را نمی‌گیرد.
نمونه‌برداری و عدم قطعیت
پروفایل نمونه‌برداری‌شده مشاهده همه فراخوانی‌ها نیست. یک مسیر کوتاه یا کم‌تکرار ممکن است در بازه کوچک دیده نشود و نبودن آن اثبات اجرا نشدنش نیست. برای بررسی چنین مسیری، بازه یا بار آزمایش را آگاهانه انتخاب کنید و هزینه جمع‌آوری را نیز بسنجید. افزایش بی‌هدف نرخ نمونه‌برداری می‌تواند روی برنامه اثر بگذارد و مقایسه را مخدوش کند.
گزارش نتیجه باید تعداد یا حجم نمونه مرتبط و شرایط بار را بیان کند. اگر تنها چند درخواست آزمایشی داشته‌اید، نتیجه را به همه ساعت‌های کاری تعمیم ندهید. بهتر است فرضیه را در بار نماینده دیگری هم بررسی کنید. این احتیاط مانع استفاده عملی از پروفایل نیست؛ کمک می‌کند تیم بداند کدام نتیجه قوی است و کدام نتیجه هنوز به داده بیشتری نیاز دارد.
