کلادفلر کش رو با zstd فشرده میکنه
خلاصهٔ کاملتر
تو بلاگ کلادفلر اومده که قیمت RAM و هارد تو یه سال گذشته حسابی بالا رفته و این مستقیم به هزینهٔ سرویسی میخوره که کل CDNـش به حافظه وابستهست. نویسنده که این پروژه رو تو دورهٔ کارآموزیش ساخته، پروتوتایپی به اسم Cache Transcoding درست کرده: بهجای اینکه فایل همونطور که از origin میاد روی دیسک بشینه، موقع ورود به کش داخل Pingora با zstd کد میشه و تا قبل از تحویل به کلاینت فشرده میمونه.
zstd یه الگوریتم فشردهسازی بدون اتلافه که Yann Collet ساخته و ۲۰۱۶ متنباز شد. بدون اتلاف یعنی بعد از باز کردن، بایتبهبایت همون فایل اولیه رو داری، پس فقط شکل ذخیرهشدن عوض میشه نه خود فایل. تو تستهای قبلی کلادفلر، ۴۲٪ سریعتر از Brotli بود با تقریباً همون حجم خروجی، و ۱۱.۳٪ کوچیکتر از gzip با سرعت مشابه. پروتوتایپ از level 3 استفاده میکنه تا پر کردن کش تبدیل به گلوگاه CPU نشه.
همهچی هم فشرده نمیشه. عکس و ویدیو و فونت از قبل فشردهن و تو نمونهٔ ترافیکشون ۲۱.۴٪ درخواستها ولی ۶۳.۳٪ بایتها بودن، پس دوباره فشرده کردنشون فقط CPU میسوزونه. در عوض متنهایی مثل HTML و JSON و CSS و JS، که ۶۷.۳٪ درخواستها و ۲۲.۳٪ بایتها بودن، حدود ۷۱ درصدشون بدون Content-Encoding میرسن و خوب هم جمع میشن. شرطها هم روشنه: پاسخ 200 OK، بدون Content-Encoding، از نوع متنی و دستکم ۴ کیبیبایت.
عددهای اندازهگیریشون اینه: نسبت فشردهسازی ۲.۸۳ برابر، هزینهٔ کد کردن ۴.۳۱ نانوثانیه بهازای هر بایت یعنی حدود ۲۳۲ مگابایت بر ثانیه که فقط یکبار موقع fill پرداخت میشه، و هزینهٔ دیکد ۱.۵۶ نانوثانیه بهازای هر بایت یعنی حدود ۶۴۱ مگابایت بر ثانیه که هر بار سرو کردن پرداخت میشه. چون هر فایل خیلی بیشتر از دفعاتی که تو کش پر میشه سرو میشه، این معامله بهصرفه درمیاد و یعنی با همون سختافزار فعلی میشه محتوای بیشتری نگه داشت.
تو مسیر Tiered Cache فایل بهشکل فشرده بین لایهٔ بالا و پایین جابهجا میشه و فقط تو آخرین گام، همونجا که به کلاینت تحویل داده میشه، دیکد میشه؛ یه نشانگر تو متادیتای کش هم جلوی دوباره کد شدن فایل رو میگیره. اول فکر کرده بودن فقط محتوای پرطرفدار رو فشرده کنن، ولی جواب نداد چون دیکد هر بار انجام میشه. نویسنده هم تأکید میکنه این هنوز پروتوتایپه و کورپوس تستشون عمداً فشردهشدنی بوده، پس عدد ۲.۸ برابر رو نباید ثابتِ کل ناوگان فرض کرد.
نکات کلیدی:
- نسبت فشردهسازی روی کورپوس تست ۲.۸۳ برابر بود، یعنی حدود یکسوم حجم اولیه روی دیسک
- کد کردن ۴.۳۱ نانوثانیه بر بایت و فقط یکبار؛ دیکد ۱.۵۶ نانوثانیه بر بایت و هر بار سرو
- فقط پاسخ 200 OK، بدون Content-Encoding، از نوع متنی و حداقل ۴ کیبیبایت واجد شرایطه
- آستانهٔ ۴ کیبیبایت کلی درخواست ریز رو کنار گذاشت و فقط حدود ۱٪ بایتهای واجد شرایط رو جا انداخت
- تست عملکرد روی بیشتر از یک میلیون درخواست و ۱۰ سرور کش، یک نیمه با Tiered Cache و یک نیمه بدونش، اجرا شد
