בקשות Squid איטיות עם כותב URL שקורס
בדקו את עוזר כתיבת ה-URL כשהפרוקסי מקבל חיבורים אך הבקשות נתקעות לפני העברה.
אם Squid מקבל חיבורים אך לוקח לו זמן רב לשלוח בקשות הלאה, בדקו כל כותב URL בדרך הזו. ב-Squid 5–7 url_rewrite_program מציין תוכנית חיצונית שמתייעצים בה לאחר בדיקות הגישה הראשוניות. היא יכולה לעכב את הבקשה לפני שהיעד מקבל אותה.
- קראו את פקודת הכתיבה האפקטיבית, כולל העטיפה והארגומנטים.
- התאימו את העסקה שנפגעה לאבחון העוזר. יציאות חוזרות של תהליכי בן, תשובות פגומות ותור גדל הם רמזים נפרדים.
- בדקו אם תבנית URL אחת מפעילה את הכשל. שמרו דוגמה מצונזרת של הקלט הזה במקום לשנות הגדרות פתרן לא קשורות.
לעוזר יש חוזה בקשה/תשובה מבוסס שורות. טקסט התקדמות של העטיפה בפלט התקני יכול לשבור אותו. גם הרצה מוצלחת של הסקריפט כמנהל אינה משחזרת את זרם הקלט, הסביבה או ההרשאות של Squid. מסלול זה נפרד מאימות סיסמה.
רק לאחר שההחלפה עובדת יש להתייחס לזה כאל בעיית קיבולת. url_rewrite_children שולט בתהליכים ובהתנהגות התור הנלווית, אך יותר תהליכי בן אינם יכולים לתקן קריסות שנגרמות מהקלט. אפשרות ההקבלה שלו מציגה מזהי ערוץ ומחייבת עוזר שמיישם את השיחה הזו.
השוואה מורשית בלי כותב ה-URL יכולה לבודד את תרומתו. השארתו בעקיפה בעומס יתר עלולה לשנות את הניתוב או הסינון שהוא אוכף, ולכן זו החלטת מדיניות. השוו את ההמתנה הנצפית של העוזר לראיות DNS ולחיבור ההמשך לפני שתייחסו את כל העיכוב להשהיית רשת.