مزایا و معایب استفاده از منطق انقضا ثابت یا متفاوت در لایههای کش سرویس و کش HTTP.
در حالی که کارگران سرویس و PWA در حال تبدیل شدن به استانداردهای برنامه های کاربردی وب مدرن هستند، کش منابع پیچیده تر از همیشه شده است. این مقاله تصویر بزرگی از کش مرورگر را پوشش می دهد، از جمله:
- موارد استفاده و تفاوتهای بین کش سرویس کارگر و حافظه پنهان HTTP.
- مزایا و معایب استراتژیهای مختلف انقضای حافظه پنهان در مقایسه با استراتژیهای معمول ذخیرهسازی HTTP.
مروری بر جریان ذخیره سازی
در سطح بالا، مرورگر هنگام درخواست منبع از ترتیب ذخیره سازی زیر پیروی می کند:
- کش سرویس : کارگر سرویس بررسی میکند که آیا منبع در حافظه پنهان است و تصمیم میگیرد که آیا خود منبع را بر اساس استراتژیهای ذخیرهسازی برنامهریزیشدهاش برگرداند یا خیر. توجه داشته باشید که این به طور خودکار اتفاق نمی افتد. شما باید یک کنترل کننده رویداد واکشی در سرویسکار خود ایجاد کنید و درخواستهای شبکه را رهگیری کنید تا درخواستها به جای شبکه، از حافظه پنهان کارمند سرویس ارائه شوند.
- حافظه پنهان HTTP (همچنین به عنوان کش مرورگر نیز شناخته می شود) : اگر منبع در حافظه پنهان HTTP یافت شود و هنوز منقضی نشده باشد، مرورگر به طور خودکار از منبع موجود در حافظه پنهان HTTP استفاده می کند.
- سمت سرور: اگر چیزی در کش سرویس یا کش HTTP یافت نشد، مرورگر برای درخواست منبع به شبکه می رود. اگر منبع در یک CDN ذخیره نشده باشد، درخواست باید تا آخر به سرور مبدا برگردد.
ذخیره سازی لایه ها
کارمند سرویس در حال ذخیره سازی
یک سرویسگر درخواستهای HTTP نوع شبکه را رهگیری میکند و از استراتژی ذخیرهسازی برای تعیین منابعی که باید به مرورگر بازگردانده شوند، استفاده میکند. کش Service Worker و کش HTTP هدف کلی یکسانی دارند، اما کش سرویسکار قابلیتهای ذخیرهسازی بیشتری را ارائه میکند، مانند کنترل دقیق بر روی دقیقاً آنچه در حافظه پنهان و نحوه ذخیرهسازی انجام میشود.
کنترل کش سرویس کارگر
یک سرویس دهنده درخواست های HTTP را با شنوندگان رویداد (معمولا رویداد fetch
) رهگیری می کند. این قطعه کد منطق یک استراتژی کش کردن Cache-First را نشان می دهد.
برای جلوگیری از اختراع مجدد چرخ، استفاده از Workbox به شدت توصیه می شود. برای مثال، میتوانید مسیرهای URL منبع را با یک خط کد regex ثبت کنید .
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
استراتژیهای ذخیرهسازی حافظه موقت و موارد استفاده از کارکنان خدمات
جدول بعدی، استراتژیهای رایج ذخیرهسازی سرویسدهنده و زمانی که هر استراتژی مفید است را نشان میدهد.
استراتژی ها | منطق طراوت | موارد استفاده کنید |
---|---|---|
فقط شبکه | محتوا باید همیشه به روز باشد. |
|
بازگشت شبکه به حافظه پنهان | ترجیحاً محتوای تازه سرو شود. اما اگر شبکه از کار بیفتد یا ناپایدار باشد، ارائه محتوای کمی قدیمی قابل قبول است. |
|
قدیمی-در حالی که-تأیید مجدد | ارائه فوراً محتوای کش اشکالی ندارد، اما در آینده باید از محتوای ذخیره شده به روز شده استفاده شود. |
|
ابتدا کش، به شبکه برگردید | محتوا غیر بحرانی است و میتواند از حافظه پنهان برای افزایش عملکرد استفاده شود، اما کارمند سرویس باید هر از گاهی برای بهروزرسانیها بررسی کند. |
|
فقط کش | محتوا به ندرت تغییر می کند. |
|
مزایای اضافی ذخیره سازی کش توسط سرویسکار
علاوه بر کنترل دقیق منطق ذخیرهسازی، ذخیرهسازی سرویسکار نیز فراهم میکند:
- حافظه و فضای ذخیره سازی بیشتر برای مبدا شما: مرورگر منابع حافظه پنهان HTTP را بر اساس مبدأ تخصیص می دهد. به عبارت دیگر، اگر چندین ساب دامنه دارید، همه آنها حافظه پنهان HTTP یکسانی دارند. هیچ تضمینی وجود ندارد که محتوای مبدا/دامنه شما برای مدت طولانی در حافظه پنهان HTTP باقی بماند. به عنوان مثال، یک کاربر ممکن است کش را با پاک کردن دستی از رابط کاربری تنظیمات مرورگر، یا راهاندازی بارگذاری مجدد سخت در صفحه، پاک کند. با یک کش سرویس، احتمال بیشتری دارید که محتوای کش شما در حافظه پنهان بماند. برای اطلاعات بیشتر به ذخیره سازی دائمی مراجعه کنید.
- انعطافپذیری بیشتر با شبکههای ورقهای یا تجربههای آفلاین: با حافظه پنهان HTTP فقط یک انتخاب باینری دارید: یا منبع ذخیره شود یا نه. با ذخیرهسازی پنهان سرویسدهنده، میتوانید «سکسکههای» کوچک را بسیار آسانتر کاهش دهید (با استراتژی «بنه-در حالی که-تأیید مجدد»)، یک تجربه آفلاین کامل (با استراتژی «فقط حافظه پنهان») یا حتی چیزی در این بین، مانند رابطهای کاربری سفارشیشده با بخشهایی از صفحه که از حافظه پنهان سرویسکار میآیند و برخی از بخشها حذف میشوند (با استراتژی «Set catch handler») در صورت لزوم.
ذخیره HTTP
اولین باری که مرورگر یک صفحه وب و منابع مرتبط را بارگیری می کند، این منابع را در حافظه پنهان HTTP خود ذخیره می کند. کش HTTP معمولاً به طور خودکار توسط مرورگرها فعال می شود، مگر اینکه کاربر نهایی آن را به صراحت غیرفعال کرده باشد.
استفاده از کش HTTP به معنای تکیه بر سرور برای تعیین زمان و مدت زمان کش کردن یک منبع است.
انقضای کش HTTP را با هدرهای پاسخ HTTP کنترل کنید
هنگامی که یک سرور به درخواست مرورگر برای منبع پاسخ می دهد، سرور از هدرهای پاسخ HTTP استفاده می کند تا به مرورگر بگوید چه مدت باید منبع را در حافظه پنهان نگه دارد. سرصفحههای پاسخ را ببینید: وب سرور خود را برای کسب اطلاعات بیشتر پیکربندی کنید .
استراتژی های ذخیره سازی HTTP و موارد استفاده
کش HTTP بسیار ساده تر از کش کردن سرویس دهنده است، زیرا کش HTTP فقط با منطق انقضای منابع مبتنی بر زمان (TTL) سروکار دارد. ببینید کدام مقادیر سرصفحه پاسخ را باید استفاده کنید؟ و خلاصه برای کسب اطلاعات بیشتر در مورد استراتژی های ذخیره سازی HTTP.
طراحی منطق انقضای حافظه پنهان
این بخش مزایا و معایب استفاده از منطق انقضای منسجم را در لایههای کش سرویس و کش HTTP و همچنین مزایا و معایب منطق انقضای جداگانه در این لایهها را توضیح میدهد.
اشکال زیر نشان می دهد که چگونه کش سرویس و کش HTTP در سناریوهای مختلف عمل می کنند:
منطق انقضا ثابت برای تمام لایه های کش
برای نشان دادن مزایا و معایب، به 3 سناریو نگاه خواهیم کرد: بلند مدت، میان مدت و کوتاه مدت.
سناریوها | کش طولانی مدت | کش میان مدت | کش کوتاه مدت |
---|---|---|---|
استراتژی ذخیره سازی کارکنان خدمات | کش، بازگشت به شبکه | قدیمی-در حالی که-تأیید مجدد | بازگشت شبکه به حافظه پنهان |
کش TTL کارگر سرویس | 30 روز | 1 روز | 10 دقیقه |
حداکثر سن HTTP cache | 30 روز | 1 روز | 10 دقیقه |
سناریو: کش طولانی مدت (کش، بازگشت به شبکه)
- هنگامی که یک منبع ذخیره شده در حافظه پنهان معتبر است (<= 30 روز): کارگر سرویس بلافاصله منبع ذخیره شده را بدون رفتن به شبکه برمی گرداند.
- هنگامی که یک منبع ذخیره شده در حافظه پنهان منقضی می شود (بیش از 30 روز): کارگر سرویس برای واکشی منبع به شبکه می رود. مرورگر یک کپی از منبع در حافظه پنهان HTTP خود ندارد، بنابراین برای منبع سمت سرور می رود.
منفی: در این سناریو، حافظه پنهان HTTP ارزش کمتری را ارائه می دهد، زیرا مرورگر همیشه درخواست را به سمت سرور ارسال می کند که کش در سرویس کارگر منقضی شود.
سناریو: حافظه پنهان میان مدت (Stale-While-Revalidate)
- هنگامی که یک منبع ذخیره شده معتبر است (<= 1 روز): کارگر سرویس بلافاصله منبع ذخیره شده را برمی گرداند و برای واکشی منبع به شبکه می رود. مرورگر یک کپی از منبع را در حافظه پنهان HTTP خود دارد، بنابراین آن کپی را به سرویسکار برمیگرداند.
- هنگامی که یک منبع ذخیره شده منقضی می شود (> 1 روز): کارگر سرویس بلافاصله منبع ذخیره شده را برمی گرداند و برای واکشی منبع به شبکه می رود. مرورگر یک کپی از منبع در حافظه پنهان HTTP خود ندارد، بنابراین برای واکشی منبع به سمت سرور می رود.
منفی: کارگر سرویس برای لغو حافظه پنهان HTTP به منظور استفاده حداکثری از مرحله "تأیید مجدد"، به حذف حافظه پنهان اضافی نیاز دارد.
سناریو: کش کوتاه مدت (بازگشت شبکه به حافظه پنهان)
- وقتی یک منبع ذخیره شده در حافظه پنهان معتبر است (<= 10 دقیقه): کارگر سرویس برای واکشی منبع به شبکه می رود. مرورگر یک کپی از منبع را در حافظه پنهان HTTP خود دارد، بنابراین آن را بدون رفتن به سمت سرور به کارمند سرویس برمی گرداند.
- هنگامی که یک منبع ذخیره شده منقضی می شود (> 10 دقیقه): کارگر سرویس بلافاصله منبع ذخیره شده را برمی گرداند و برای واکشی منبع به شبکه می رود. مرورگر یک کپی از منبع در حافظه پنهان HTTP خود ندارد، بنابراین برای واکشی منبع به سمت سرور می رود.
منفی: مشابه سناریوی حافظه پنهان میانمدت، سرویسکار به منطق مخرب اضافی نیاز دارد تا کش HTTP را لغو کند تا آخرین منبع را از سمت سرور دریافت کند.
کارگر خدماتی در همه حالات
در تمام سناریوها، کش سرویس کارگر همچنان میتواند منابع ذخیرهشده را در زمانی که شبکه ناپایدار است بازگرداند. از سوی دیگر، کش HTTP زمانی که شبکه ناپایدار یا قطع است قابل اعتماد نیست.
منطق انقضای کش مختلف در کش سرویس و لایه های HTTP
برای نشان دادن مزایا و معایب، ما دوباره به سناریوهای بلند مدت، میان مدت و کوتاه مدت نگاه خواهیم کرد.
سناریوها | کش طولانی مدت | کش میان مدت | کش کوتاه مدت |
---|---|---|---|
استراتژی ذخیره سازی کارکنان خدمات | کش، بازگشت به شبکه | قدیمی-در حالی که-تأیید مجدد | بازگشت شبکه به حافظه پنهان |
کش TTL کارگر سرویس | 90 روز | 30 روز | 1 روز |
حداکثر سن HTTP cache | 30 روز | 1 روز | 10 دقیقه |
سناریو: کش طولانی مدت (کش، بازگشت به شبکه)
- هنگامی که یک منبع ذخیره شده در حافظه پنهان سرویس دهنده معتبر است (<= 90 روز): کارگر سرویس بلافاصله منبع ذخیره شده را برمی گرداند.
- هنگامی که یک منبع ذخیره شده در حافظه پنهان سرویس دهنده منقضی می شود (بیش از 90 روز): کارگر سرویس برای واکشی منبع به شبکه می رود. مرورگر یک کپی از منبع در حافظه پنهان HTTP خود ندارد، بنابراین به سمت سرور می رود.
مزایا و معایب:
- حرفه ای: کاربران پاسخ فوری را تجربه می کنند زیرا کارگر سرویس منابع ذخیره شده را بلافاصله برمی گرداند.
- طرفدار: سرویسکار کنترل دقیقتری در مورد زمان استفاده از حافظه پنهان و زمان درخواست نسخههای جدید منابع دارد.
- منفی: یک استراتژی ذخیره سازی سرویس دهنده به خوبی تعریف شده مورد نیاز است.
سناریو: حافظه پنهان میان مدت (Stale-While-Revalidate)
- هنگامی که یک منبع ذخیره شده در حافظه پنهان سرویس دهنده معتبر است (<= 30 روز): کارگر سرویس بلافاصله منبع ذخیره شده را برمی گرداند.
- هنگامی که یک منبع ذخیره شده در حافظه پنهان سرویس دهنده منقضی می شود (بیش از 30 روز): کارگر سرویس برای منبع به شبکه می رود. مرورگر یک کپی از منبع در حافظه پنهان HTTP خود ندارد، بنابراین به سمت سرور می رود.
مزایا و معایب:
- حرفه ای: کاربران پاسخ فوری را تجربه می کنند زیرا کارگر سرویس منابع ذخیره شده را بلافاصله برمی گرداند.
- حرفه ای: کارمند سرویس می تواند اطمینان حاصل کند که درخواست بعدی برای یک URL معین از یک پاسخ تازه از شبکه استفاده می کند، به لطف اعتبارسنجی مجدد که "در پس زمینه" اتفاق می افتد.
- منفی: یک استراتژی ذخیره سازی سرویس دهنده به خوبی تعریف شده مورد نیاز است.
سناریو: کش کوتاه مدت (بازگشت شبکه به حافظه پنهان)
- هنگامی که یک منبع ذخیره شده در حافظه پنهان سرویس دهنده معتبر است (<= 1 روز): کارگر سرویس برای منبع به شبکه می رود. مرورگر منبع را از کش HTTP در صورت وجود آن برمی گرداند. اگر شبکه قطع باشد، سرویسکار منبع را از کش سرویسکار برمیگرداند
- هنگامی که یک منبع ذخیره شده در حافظه پنهان سرویس دهنده منقضی می شود (> 1 روز): کارگر سرویس برای واکشی منبع به شبکه می رود. مرورگر منابع را از طریق شبکه واکشی می کند زیرا نسخه کش در حافظه پنهان HTTP منقضی شده است.
مزایا و معایب:
- حرفه ای: هنگامی که شبکه ناپایدار یا خاموش است، سرویس دهنده منابع ذخیره شده را بلافاصله برمی گرداند.
- منفی: کارگر سرویس برای لغو حافظه پنهان HTTP و درخواستهای "اول شبکه" به حذف حافظه پنهان اضافی نیاز دارد.
نتیجه گیری
با توجه به پیچیدگی ترکیب سناریوهای حافظه پنهان، نمی توان یک قانون طراحی کرد که همه موارد را پوشش دهد. با این حال، بر اساس یافتههای بخشهای قبلی، چند پیشنهاد برای طراحی استراتژیهای کش وجود دارد:
- نیازی نیست که منطق کش کردن سرویسدهندگان با منطق انقضای ذخیرهسازی HTTP سازگار باشد. در صورت امکان، از منطق انقضای طولانیتر در سرویسکار استفاده کنید تا کنترل بیشتری به کارگر خدمات بدهید.
- کش HTTP هنوز نقش مهمی ایفا می کند، اما زمانی که شبکه ناپایدار یا قطع است قابل اعتماد نیست.
- استراتژیهای کش خود را برای هر منبع مجدداً بررسی کنید تا مطمئن شوید که استراتژی ذخیرهسازی سرویسدهنده ارزش آن را بدون تضاد با حافظه پنهان HTTP فراهم میکند.