מתי מטמון פרוקסי משותף עוזר לסורק
העריכו משאבים חוזרים, רעננות ובקשות אמת של הסורק לפני שמצפים שמטמון פרוקסי קדמי משותף ישפר תפוקה.
נניח שכמה עובדים בדפדפן פותחים עמודים שונים מאותו אתר. העמודים האלה מפנים לאותו גיליון סגנון, לוגו וחבילת סקריפטים. מטמון קדמי משותף יכול להפוך את הבקשה הראשונה לשימושית לעובדים מאוחרים יותר כאשר ניתן לעשות שימוש חוזר בתגובות.
כעת שנו את עומס העבודה: כל עובד מוריד מסמך HTML אחד בלבד ואינו טוען לעולם את המשאבים המקושרים אליו. גיליון הסגנון המשותף עדיין נמצא בסימון, אבל אף עובד לא מבקש אותו. הוא אינו תורם דבר לשיעור הפגיעות במטמון של הפרוקסי.
התחילו בבקשות שהסורק שלכם באמת שולח
דפדפן שמציג עמוד ולקוח HTTP שמושך את המקור שלו יוצרים קבוצות בקשות שונות. בדקו את הקבוצות האלה לפני בחירת תכנון מטמון.
| עומס עבודה | פוטנציאל לשימוש חוזר משותף |
|---|---|
| עובדים מושכים שוב ושוב את אותם נכסים ציבוריים | שימושי כאשר כללי רעננות ומפתח מטמון מתירים זאת |
| לכל בקשה יש כתובת ייחודית או גרסת תגובה | מעט חפיפה לשימוש חוזר |
| תגובה זקוקה לאימות מחדש לפני שימוש חוזר | עשויה לחסוך בייטים של תגובה ועדיין דורשת מסע למעלה |
| עובדים כבר מספקים בקשות מהמטמון המקומי שלהם | ייתכן שהבקשות האלה לא יגיעו לעולם לפרוקסי המשותף |
שוויון בכתובת בלבד אינו מספיק. מדיניות הרעננות של התגובה ושדות שנקראים על ידי Vary יכולים להבחין בין ייצוגים. תוכן פרטי, שאינו ניתן לאחסון או מאומת זקוק לכללים החלים של מטמון משותף; אין לכפות אותו לתוצאה ציבורית אחת רק כדי להעלות את מספר הפגיעות.
בתעבורת HTTPS CONNECT רגילה, הפרוקסי הקדמי נושא מנהרה מוצפנת ואין בתוכה אובייקטים של HTTP לאחסון. פריסה עם בדיקת TLS מתנהגת אחרת מבחינת אמון ועיבוד. כללו את המצב בפועל כשאתם מעריכים אם אחסון אובייקטים זמין.
פגיעה במטמון יכולה לחסוך משיכה מהמעלה, בעוד שהחמצה עדיין משלמת על עבודת המתווך. השוו בייטים שימושיים שהושלמו, תעבורה למעלה והשהיה עבור עומס העבודה המיועד. מספר התהליכונים מתאר מקביליות; הוא אינו מתאר כמה תוכן לשימוש חוזר חולקים התהליכונים האלה.