Redis و Intel بر روی یک «zero-touch» اتوماسیون عملکرد و پروفایلگیری همکاری میکنند تا توانایی Redis برای پیگیری رگرسیونهای عملکرد و بهبود کارایی کد پایگاهداده را گسترش دهند.
یک قالب استاندارد: انگیزهها و الزامات
ردیس و اینتل در حال همکاری برای خودکارسازی «بدون لمس» عملکرد و پروفایلگیری هستند تا قابلیت ردیِس برای پیگیری افتهای عملکردی و بهبود کارایی کدهای پایگاهداده را گسترش دهند. مشخصات بنچمارکهای ردیِس نیازمندیها و انتظارات ابزارها و زبانهای مختلف را توصیف میکند تا استانداردهای عملکرد و قابلیت مشاهده را در فناوریهای مرتبط با ردیِس تقویت کند.
دلیل اصلی محبوبیت ردیِس به عنوان یک پایگاهداده کلید‑مقدار، عملکرد آن است که با زمان پاسخ زیر یک میلیثانیه برای پرسوجوها سنجیده میشود. برای ادامه بهبود عملکرد در اجزای ردیِس، ردیِس و اینتل با هم چارچوبی برای اجرای خودکار تستهای عملکرد، جمعآوری تِلِمتری، پروفایلگیری و تجسم دادهها پس از ارسال کد توسعه دادند. هدف ساده است: شناسایی تغییرات عملکردی در اسرع وقت.
این خودکارسازی به شرکای سختافزاری، مانند اینتل، بینشها دربارهٔ نحوهٔ استفاده نرمافزار از پلتفرم میدهد و فرصتهایی برای بهینهسازی بیشتر ردیِس بر روی CPUهای اینتل شناسایی میکند. مهمتر از همه، درک عمیقتر نرمافزار به اینتل کمک میکند محصولات بهتری طراحی کند.
در این پست وبلاگ، توضیح میدهیم ردیِس و اینتل چگونه بر روی این نوع خودکارسازی همکاری میکنند. پروفایلگیری «بدون لمس» میتواند پیگیری افتهای عملکردی را گسترش داده و فرصتهای بهبود کارایی کدهای پایگاهداده را کشف کند.
پیادهسازی استاندارد SPEC
هر دو ردیِس و اینتل میخواهند فرصتهای بهینهسازی نرمافزار و سختافزار را شناسایی کنند. برای این منظور، تصمیم گرفتیم مجموعهای از استانداردهای متقابل شرکتی و جامعهای در تمام موارد مرتبط با نیازها و انتظارات عملکرد و قابلیت مشاهده ایجاد کنیم.
از دیدگاه نرمافزاری، هدف ما شناسایی خودکار افتهای عملکردی و درک عمیقتر نقاط بحرانی برای یافتن فرصتهای بهبود است. ما میخواهیم چارچوب به آسانی نصب شود، پوشش جامعی از موارد تست داشته باشد و به راحتی گسترش یابد. هدف این است که بنچمارکها، ابزارهای بنچمارک و مکانیزمهای ردیابی/پروب کردن سفارشی را پشتیبانی کند.
از دیدگاه سختافزاری، میخواهیم نسلهای مختلف پلتفرمها را مقایسه کنیم تا تاثیر ویژگیهای جدید سختافزاری را ارزیابی کنیم. علاوه بر این، قصد داریم تِلِمتری جمعآوری کنیم و تستهای «اگر‑چگونه» مانند مقیاسگذاری فرکانس، مقیاسگذاری هسته و آزمونهای فعال/غیرفعال پیشبارگذارهای کش را انجام دهیم. این به ما کمک میکند تأثیر هر یک از این بهینهسازیها بر عملکرد ردیِس را جدا کرده و تصمیمات بهینهسازی و معماری آینده CPU و پلتفرمها را شکل دهیم.
پیادهسازی استاندارد SPEC
بر پایهٔ مبنای ذکر شده، چارچوب مشخصات بنچمارکهای ردیِس را ایجاد کردیم. این چارچوب به راحتی از طریق PyPi قابل نصب است و روشهای سادهای برای ارزیابی عملکرد ردیِس و سیستمهای زیرساختی که ردیِس روی آن اجرا میشود، ارائه میدهد. مشخصات بنچمارک ردیِس در حال حاضر حدود ۶۰ بنچمارک متمایز دارد که چندین فرمان و ویژگی را پوشش میدهند. این چارچوب به راحتی میتواند با بنچمارکهای سفارشی، ابزارهای بنچمارک و مکانیزمهای ردیابی یا پروب شما گسترش یابد.
ردیس و اینتل به طور پیوسته بنچمارکهای چارچوب را اجرا میکنند. ما هر نتیجهٔ بنچمارک را بر حسب شاخه و برچسب تجزیه میکنیم و دادههای عملکردی بهدستآمده را در طول زمان و بر اساس نسخه تفسیر مینماییم. علاوه بر این، از این ابزار برای تأیید درخواستهای pull مرتبط با عملکرد در پروژه ردیِس استفاده میکنیم. فرایند تصمیمگیری شامل نتایج بنچمارک و توضیح دلایل این نتایج است که با استفاده از خروجی ابزارهای پروفایلگیری و پروبها در حالت «بدون لمس» کاملاً خودکار بهدست میآید.
نتیجه: میتوانیم بینشهای سطح پلتفرم تولید کنیم و تحلیلهای «اگر‑چگونه» انجام دهیم. این امکان به لطف ابزارهای ردیابی و پروب منبع باز مانند memtier_benchmark، redis-benchmark، Linux perf_events، ابزارهای ردیابی bcc/BPF، مخزن FlameGraph برندان گرگ و Intel Performance Counter Monitor برای جمعآوری دادههای تِلِمتری مرتبط با سختافزار فراهم میشود.
اگر به جزئیات بیشتری دربارهٔ نحوه استفادهٔ ما از پروفایلگرها با ردیِس علاقهمندید، راهنمای بسیار تفصیلی مهندسی عملکرد برای پروفایلگیری و ردیابی روی CPU را ببینید.
پس، این چطور کار میکند؟ خوشحالیم که پرسیدید.
معماری نرمافزار
هدف اصلی مشخصات بنچمارکهای ردیِس شناسایی تغییرات عملکردی در اسرع وقت است. این بدین معنی است که میتوانیم (یا باید) اثر عملکردی تغییرات اعمالشده را، همانطور که در چندین بنچمارک اندازهگیری میشود، به محض اینکه مجموعهای از تغییرات به گیت ارسال شد، ارزیابی کنیم.
یکی از اثرات مثبت این است که نگهدارندگان اصلی ردیِس کار آسانتری دارند. فعالسازی بنچمارکهای CI/CD تنها با برچسبگذاری یک درخواست pull خاص (PR) با ‘action run:benchmarks’ انجام میشود. این تراگر سپس به یک رویداد (در ردیِس پیگیری میشود) تبدیل میشود که بر پایهٔ پلتفرمهای متمایز توصیفشده در مرجع پلتفرمهای مشخصات بنچمارک ردیِس درخواستهای مختلف ساخت را آغاز میکند.
هنگامی که درخواست یک نوع ساخت جدید دریافت میشود، عامل ساخت (redis-benchmarks-spec-builder) آثار (artifact) را آماده میکند. این عامل یک رویداد بنچمارک آثار را اضافه میکند تا تمام پلتفرمهای بنچمارک (از جمله آنهایی که در آزمایشگاه اینتل هستند) بتوانند به رویدادهای اجرای بنچمارک گوش دهند. این همچنین فرایند استقرار و مدیریت زیرساختهای مورد نیاز و توپولوژیهای پایگاهداده، اجرای بنچمارکها و استخراج نتایج عملکرد را آغاز میکند. تمام دادهها در ردیِس ذخیره میشوند (با استفاده از ویژگیهای Redis Stack). بعدها برای تحلیل مبتنی بر واریانس بین ساختهای پایه و مقایسهای (مانند مثال تصویر زیر) و برای تحلیل واریانس زمانی بر روی همان شاخه/برچسب استفاده میشود.
کامیتهای جدید در همان شاخه کاری مجموعهای از رویدادهای بنچمارک جدید تولید میکنند و فرایند فوق را تکرار مینمایند.
شکل ۱. معماری پلتفرم از مرحلهٔ فعالسازی یک جریان کاری از درخواست pull تا تولید دادههای نهایی بنچمارک و پروفایلگیری.
پیکربندی سختافزاری آزمایشگاه اینتل
این چارچوب میتواند هم بهصورت درونسازمانی (on‑prem) و هم در ابر مستقر شود. در همکاری ما، اینتل یک خوشهٔ سرورهای درونسازمانی میزبانی میکند که به طور اختصاصی به چارچوب تست خودکار همیشهفعال عملکرد اختصاص دارد (به شکل ۲ مراجعه کنید).
شکل ۲. تنظیمات آزمایشگاه اینتل
این خوشه شامل شش سرور نسل فعلی (IceLake) و شش سرور نسل قبلی (CascadeLake) است که به یک سوئیچ سرعتبالای ۴۰ Gb متصل هستند (به شکل ۳ مراجعه کنید). سرورهای قدیمی برای تست عملکرد در میان نسلهای سختافزاری و همچنین برای تولید بار در بنچمارکهای مشتری‑سرور استفاده میشوند.
ما قصد داریم آزمایشگاه را برای شامل شدن چندین نسل سرور گسترش دهیم، از جمله پلتفرمهای BETA (پیشانتشار) برای ارزیابی زودهنگام و تحلیلهای «اگر‑چگونه» ویژگیهای پیشنهادی پلتفرم.
یکی از مزایای مشاهدهشدهٔ تنظیمات درونسازمانی اختصاصی این است که میتوانیم نتایج پایدارتر با تغییرات کمتر بین اجرایها بهدست آوریم. علاوه بر این، انعطافپذیری برای افزودن یا حذف مؤلفهها بهصورت دلخواه در سرورها داریم.
شکل ۳. پیکربندی سرور
نگاهی به آینده
امروز، مشخصات بنچمارکهای ردیِس بهعنوان ابزار مجموعهای استاندارد تست عملکرد در ردیِس توسط تیم عملکرد مورد استفاده قرار میگیرد. این ابزار تقریباً ۶۰ بنچمارک را در یکپارچگی مستمر (CI) روزانه اجرا میکند و ما همچنین از آن برای بررسیهای دستی عملکرد بهره میبریم.
ما از مزایا پیشاپیش بهرهمند شدیم. در دورهٔ توسعه Redis 7.0 و ۷.۲، مشخصات جدید قبلاً به ما امکان آمادهسازی بهبودهای تازه را همانند موارد موجود در این درخواستهای pull داده است:
- تغییر بهینهسازیهای کامپایلر به -O3 -flto. افزایش عملکرد تا ۵٪ در تستهای SPEC بنچمارک اندازهگیری شد.
- استفاده یکبار از snprintf در addReplyDouble. بهبود حدود ۲۵٪ در عملیات ساده ZADD اندازهگیری شد.
- انتقال پرچمهای کاربر به موقعیتی دوستانهتر برای کش در ساختار client. ۲٪ از چرخههای CPU که از نسخه v6.2 از دست رفته بود، بازگردانده شد.
- بهینهسازی d2string() و addReplyDouble() با grisu2. اگر به تأثیر فرمان ZRANGE WITHSCORES نگاهی بیندازیم، بهبود ۲۳٪ در ops/sec قابلدسترس برای پاسخهای ۱۰ عنصری، ۵۰٪ برای پاسخهای ۱۰۰ عنصری و ۶۸٪ برای پاسخهای ۱٬۰۰۰ عنصری مشاهده شد.
- بهینهسازی ایجاد stream id sds در XADD key *. نتایج: تقریباً ۲۰٪ از چرخههای CPU صرفهجویی شد.
- استفاده از زمانسنجی مونوٹونیک یا زمانسنج دیوار ساعت برای اندازهگیری زمان اجرای فرمان. تا ۴٪ زمان اجرای بهبود یافت.
- پرکاشیدن پاسخ آرایهٔ به تأخیر افتاده در فرمانهای ZRANGE BYRANK. از ۳ تا ۱۵٪ عملکرد از دسترفته از نسخه v5 به دلیل ویژگیهای افزوده بهدست آمد.
- بهینهسازی پاسخهای به تأخیر افتاده برای استفاده از اشیاء مشترک به جای sprintf. بهبود اندازهگیریشده از ۳٪ تا ۹٪ در فرمان ZRANGE.
بهطور خلاصه، کارهای فوق امکان ارتقاء عملکرد تا ۶۸٪ برای دستورات تحت پوشش را فراهم کردند.
شکل ۴. نمونهای از تجسم در Grafana گروه توسعهدهندگان ردیِس که عملکرد هر پلتفرم/بنچمارک/نسخه را در طول زمان پیگیری میکند.
کارهای آینده
سیستم مهندسی عملکرد فعلی ما امکان شناسایی تغییرات عملکردی در طول چرخه توسعه را فراهم میکند و به توسعهدهندگان ما اجازه میدهد تا تأثیر تغییرات کد خود را درک کنند. باوجود پیشرفتهای قابلتوجه، هنوز زمینههای بسیاری برای بهبود وجود دارد.
ما در حال کار بر روی بهبود توانایی تجمیع دادههای عملکردی در میان مجموعهای از بنچمارکها هستیم. این امکان را میدهد تا به سؤالاتی مانند: «کدام استکهای مصرف‑CPU برتر در تمام بنچمارکها هستند؟» و «کدام بهسادگی قابل بهینهسازی است که بیشترین اثر را بر تمام دستورات داشته باشد؟» پاسخ دهیم.
علاوه بر این، تحلیل ما بین پایه و مقایسه به شدت به محاسبه سادهٔ مبتنی بر واریانس وابسته است. ما قصد داریم به روشهای بهتر آماری رویکرد داشته باشیم که اجازهٔ تحلیل مبتنی بر روند بر روی بیش از یک مجموعه نقاط داده و تحلیل دقیقتر برای اجتناب از «مسأله قورباغه جوشان» در محیطهای پرنوفهٔ ابر را بدهد.
API ردیِس بیش از ۴۰۰ فرمان دارد. ما باید بهدنبال افزایش شفافیت و بهبود عملکرد در تمام API باشیم. در عین حال باید بر روی پرکاربردترین دستورات که توسط جامعه و بازخورد مشتریان تعیین میشوند، تمرکز کنیم.
ما انتظار داریم گزینههای استقرار را گسترش دهیم، از جمله بنچمارکگیری در سطح خوشه، تکثیر و موارد دیگر. قصد داریم قابلیتهای تجسم و تحلیل را گسترش دهیم و تست را به پلتفرمهای سختافزاری بیشتری، از جمله پلتفرمهای اولیه (پیشانتشار) اینتل، گسترش دهیم.
هدف ما افزایش استفاده از پلتفرم عملکردی ما در میان جامعه و گروه توسعهدهندگان ردیِس است. هرچه دادهها و نگاههای متفاوت بیشتری به این پروژه اضافه کنیم، احتمال ارائه یک ردیِس سریعتر Redis افزایش مییابد.
پست های مرتبط