เมื่อใดแคชพร็อกซีที่แชร์ช่วยให้ครอว์เลอร์ทำงานดีขึ้น
ประเมินทรัพยากรที่เกิดซ้ำ ความสดใหม่ และคำขอจริงของครอว์เลอร์ก่อนคาดหวังว่าแคช forward-proxy ที่แชร์จะเพิ่มปริมาณงาน
สมมติว่าผู้ทำงานหลายคนในเบราว์เซอร์เปิดหน้าต่างๆ จากไซต์เดียว หน้าเหล่านี้อ้างอิงสไตล์ชีต โลโก้ และชุดสคริปต์เดียวกัน แคช forward ที่แชร์สามารถทำให้การดึงครั้งแรกมีประโยชน์ต่อผู้ทำงานภายหลังเมื่อนำการตอบกลับกลับมาใช้ซ้ำได้
ตอนนี้เปลี่ยนภาระงาน: ผู้ทำงานแต่ละคนดาวน์โหลดเอกสาร HTML เพียงฉบับเดียวและไม่โหลดทรัพยากรที่เชื่อมโยงเลย สไตล์ชีตร่วมยังอยู่ในมาร์กอัป แต่ไม่มีผู้ทำงานคนใดร้องขอ สิ่งนี้ไม่ได้เพิ่มอะไรให้กับอัตราการติดแคชของพร็อกซี
เริ่มจากคำขอที่ครอว์เลอร์ของคุณทำจริง
เบราว์เซอร์ที่แสดงผลหน้าและไคลเอนต์ HTTP ที่ดึงซอร์สของหน้านั้นสร้างชุดคำขอที่ต่างกัน ตรวจสอบชุดเหล่านั้นก่อนเลือกการออกแบบแคช
| ภาระงาน | ศักยภาพในการใช้ซ้ำร่วมกัน |
|---|---|
| ผู้ทำงานดึงสินทรัพย์สาธารณะเดียวกันซ้ำๆ | มีประโยชน์เมื่อกฎความสดใหม่และคีย์แคชอนุญาต |
| ทุกคำขอมี URL หรือรูปแบบการตอบกลับที่ไม่ซ้ำ | ทับซ้อนน้อยที่จะใช้ซ้ำ |
| การตอบกลับต้องตรวจสอบความถูกต้องใหม่ก่อนใช้ซ้ำ | อาจประหยัดไบต์ของการตอบกลับแต่ยังต้องเดินทางขึ้นต้นทาง |
| ผู้ทำงานตอบสนองคำขอจากแคชภายในของตนเองอยู่แล้ว | คำขอเหล่านั้นอาจไม่ถึงพร็อกซีที่แชร์เลย |
ความเท่ากันของ URL เพียงอย่างเดียวไม่พอ นโยบายความสดใหม่ของการตอบกลับและ ฟิลด์ที่ Vary ระบุสามารถแยกความแตกต่างของการนำเสนอได้ เนื้อหาส่วนตัว จัดเก็บไม่ได้ หรือผ่านการพิสูจน์ตัวตน ต้องใช้กฎแคชที่แชร์ซึ่งบังคับใช้ ไม่ควรบังคับให้รวมเป็นผลลัพธ์สาธารณะเพียงผลเดียวเพื่อเพิ่มจำนวนการติด
สำหรับทราฟฟิก HTTPS CONNECT ทั่วไป พร็อกซี forward พาเทอร์เนลที่เข้ารหัส และไม่มีออบเจ็กต์ HTTP อยู่ข้างในให้แคช การติดตั้งที่มีการตรวจสอบ TLS มีพฤติกรรมความเชื่อถือและการประมวลผลต่างกัน ควรระบุโหมดจริงเมื่อประเมินว่ามีแคชออบเจ็กต์หรือไม่
การติดแคชสามารถหลีกเลี่ยงการดึงจากต้นทางได้ ขณะที่การพลาดยังต้องจ่ายงานของตัวกลางอยู่ เปรียบเทียบไบต์ที่มีประโยชน์ที่เสร็จสมบูรณ์ ทราฟฟิกขึ้นต้นทาง และความหน่วงสำหรับภาระงานที่ตั้งใจ จำนวนเธรดอธิบายความพร้อมกัน ไม่ได้อธิบายว่าเธรดเหล่านี้แชร์เนื้อหาที่ใช้ซ้ำได้มากน้อยเพียงใด