در زیرساخت 1.1.1.1، Gateway DNS، DNS Firewall، AS112 و چند سرویس دیگر Cloudflare، سامانه Big Pineapple بیش از ۲۵۰ میلیارد ورودی DNS cache را در هر لحظه نگه می‌دارد. در چنین مقیاسی، حتی هدررفت یک بایت برای هر ورودی، به بیش از ۲۵۰ گیگابایت مصرف اضافه‌ی memory در کل fleet تبدیل می‌شود. 😮
با پنج تغییر پیاپی در نحوه ذخیره‌سازی cache entryها در memory، حجم مصرفی هر ورودی بیش از ۵۰ درصد کاهش پیدا کرد. نتیجه این بهینه‌سازی‌ها در سطح fleet، آزاد شدن حدود ۱۰۰ terabytes memory بود؛ رقمی که تقریباً با RAM موردنیاز ۱۳۰ سرور Gen 13 برابری می‌کند. علاوه بر این، cache سریع‌تر هم شد: نرخ درج ۴۳ درصد افزایش یافت و latency جست‌وجو ۱۹ درصد کمتر شد، چون تعداد allocationها پایین آمد و localy of memory بهتر شد؛ یعنی هم فضا کمتر مصرف شد و هم سرعت قربانی نشد. 🚀
وقتی Big Pineapple با cold start بالا می‌آید، cache آن خالی است. با ورود DNS queryها، cache به‌تدریج پر می‌شود تا به سقف تعداد entryها برسد؛ در این نقطه، داده‌های قدیمی‌تر یا کم‌مصرف‌تر حذف می‌شوند تا جا برای درخواست‌های جدید باز شود.
اندازه دقیق cache در هر data center یکسان نیست. در شرایطی که EDNS Client Subnet (ECS) فعال باشد، authoritative serverها بسته به شبکه‌ی کاربر پاسخ‌های متفاوتی می‌دهند؛ بنابراین باید چند نسخه از یک query واحد را cache کنیم. همین موضوع هم تعداد entryها را بالا می‌برد و هم memory مصرفی هر entry را بیشتر می‌کند، به همین دلیل بهینه‌سازی‌های این مطلب برای موقعیت‌هایی که ECS در آن‌ها زیاد استفاده می‌شود، اثر بسیار بیشتری دارد. 🔧
هر item در cache در اصل یک key-value pair است. key مشخص می‌کند چه چیزی query شده است:
pub struct CacheKey { qname: Name, qtype:
