Cereri Squid lente cu un rewriter de URL care se prăbușește

Dacă Squid acceptă conexiuni, dar durează mult până trimite cererile mai departe, verificați orice rewriter de URL de pe acea cale. În Squid 5–7, url_rewrite_program desemnează un program extern consultat după verificările inițiale de acces. El poate întârzia cererea până când destinația o primește.

1. Citiți comanda efectivă de rescriere, inclusiv wrapper-ul și argumentele.
2. Corelați tranzacția afectată cu diagnosticarea ajutorului. Ieșirile repetate ale proceselor copil, răspunsurile malformate și o coadă crescândă sunt indicii distincte.
3. Verificați dacă un singur model de URL declanșează eșecul. Păstrați un exemplu redactat al acelei intrări, în loc să modificați setări de resolver fără legătură.

Ajutorul are un contract cerere/răspuns orientat pe linii. Textul de progres al wrapper-ului pe ieșirea standard îl poate rupe. Nici rularea cu succes a scriptului ca administrator nu reproduce fluxul de intrare, mediul sau permisiunile lui Squid. Această cale este separată de verificarea parolei.

Abia după ce schimbul funcționează ar trebui tratat ca problemă de capacitate. url_rewrite_children controlează procesele și comportamentul cozii aferente, dar mai multe procese copil nu repară prăbușirile cauzate de intrare. Opțiunea sa de concurență introduce identificatori de canal și cere un ajutor care implementează acea conversație.

O comparație autorizată fără rewriter poate izola contribuția acestuia. Dacă îl lăsați ocolit la suprasarcină, se poate schimba rutarea sau filtrarea pe care o impune, deci este o decizie de politică. Comparați așteptarea observată a ajutorului cu dovezile DNS și ale conexiunii următoare înainte de a atribui întreaga întârziere latenței rețelei.