فرض کنید چند کارگر در مرورگر صفحه‌های متفاوتی از یک سایت را باز می‌کنند. آن صفحه‌ها به یک برگه سبک، لوگو و بسته اسکریپت یکسان ارجاع می‌دهند. کش پیش‌رو مشترک می‌تواند واکشی نخست را برای کارگران بعدی سودمند کند، وقتی پاسخ‌ها قابل استفاده دوباره باشند.

اکنون بار کاری را تغییر دهید: هر کارگر فقط یک سند HTML دانلود می‌کند و هرگز منابع پیوندشده آن را بارگذاری نمی‌کند. برگه سبک مشترک هنوز در نشانه‌گذاری وجود دارد، اما هیچ کارگری آن را درخواست نمی‌کند. این چیزی به نرخ برخورد کش پروکسی نمی‌افزاید.

با درخواست‌هایی شروع کنید که خزنده شما واقعاً می‌فرستد

مرورگری که صفحه را می‌آراید و کارخواه HTTP که منبع آن را می‌آورد مجموعه‌های درخواست متفاوتی می‌سازند. پیش از انتخاب طرح کش، آن مجموعه‌ها را بررسی کنید.

بار کاریتوان استفاده دوباره مشترک
کارگران مکرراً همان دارایی‌های عمومی را واکشی می‌کنندزمانی سودمند است که قواعد تازگی و کلید کش اجازه دهند
هر درخواست نشانی یا گونه پاسخ یگانه داردهمپوشانی کم برای استفاده دوباره
پاسخ پیش از استفاده دوباره به اعتبارسنجی مجدد نیاز داردممکن است بایت‌های پاسخ را ذخیره کند، اما هنوز سفر به بالادست لازم است
کارگران از پیش درخواست‌ها را از کش محلی خود برمی‌آورندآن درخواست‌ها شاید هرگز به پروکسی مشترک نرسند

تنها برابری نشانی کافی نیست. سیاست تازگی پاسخ و فیلدهایی که Vary نام می‌برد می‌توانند بازنمایی‌ها را از هم جدا کنند. محتوای خصوصی، ذخیره‌نشدنی یا تأییدشده به قواعد کش مشترک مربوط نیاز دارد؛ نباید فقط برای بالا بردن شمار برخورد به یک نتیجه عمومی واحد رانده شود.

برای ترافیک معمول HTTPS CONNECT، پروکسی پیش‌رو تونلی رمزنگاری‌شده حمل می‌کند و هیچ شیء HTTP درون آن برای کش کردن ندارد. استقرار با بازرسی TLS رفتار اعتماد و پردازش متفاوتی دارد. هنگام ارزیابی دسترس‌پذیری کش اشیا، حالت واقعی را در نظر بگیرید.

برخورد کش می‌تواند از واکشی بالادست جلوگیری کند، در حالی که خطا همچنان هزینه کار واسطه را می‌پردازد. بایت‌های سودمند کامل‌شده، ترافیک بالادست و تأخیر را برای بار کاری موردنظر مقایسه کنید. شمار رشته‌ها هم‌زمانی را توصیف می‌کند؛ توصیف نمی‌کند که آن رشته‌ها چه مقدار محتوای قابل استفاده دوباره را شریک‌اند.

مقالات مرتبط