Langsame Squid-Anfragen mit einem abstürzenden URL-Rewriter

Wenn Squid Verbindungen annimmt, aber lange braucht, um Anfragen weiterzusenden, prüfen Sie jeden URL-Rewriter auf diesem Pfad. In Squid 5–7 benennt url_rewrite_program ein externes Programm, das nach den ersten Zugriffsprüfungen konsultiert wird. Es kann die Anfrage verzögern, bevor das Ziel sie erhält.

1. Lesen Sie den tatsächlich wirksamen Rewriter-Befehl einschließlich Wrapper und Argumenten.
2. Ordnen Sie die betroffene Transaktion der Helper-Diagnose zu. Wiederholte Kindprozess-Austritte, fehlerhafte Antworten und eine wachsende Warteschlange sind unterschiedliche Spuren.
3. Prüfen Sie, ob ein einzelnes URL-Muster den Fehler auslöst. Bewahren Sie ein redigiertes Beispiel dieser Eingabe auf, anstatt unabhängige Resolver-Einstellungen zu ändern.

Der Helper hat einen zeilenorientierten Anfrage-/Antwort-Vertrag. Fortschrittstext des Wrappers auf der Standardausgabe kann ihn brechen. Auch ein erfolgreicher Skriptlauf als Administrator bildet Squids Eingabestrom, Umgebung und Berechtigungen nicht nach. Dieser Pfad ist von der Passwortprüfung getrennt.

Erst wenn der Austausch funktioniert, sollten Sie es als Kapazitätsproblem behandeln. url_rewrite_children steuert Prozesse und das zugehörige Warteschlangenverhalten, aber mehr Kindprozesse können durch Eingaben ausgelöste Abstürze nicht reparieren. Seine Nebenläufigkeitsoption führt Kanal-IDs ein und verlangt einen Helper, der diesen Dialog umsetzt.

Ein autorisierter Vergleich ohne den Rewriter kann seinen Anteil isolieren. Ihn unter Überlast umgangen zu lassen, kann das von ihm erzwungene Routing oder Filtern ändern, also ist das eine Richtlinienentscheidung. Vergleichen Sie die beobachtete Helper-Wartezeit mit DNS- und Weiterleitungsbelegen, bevor Sie die gesamte Verzögerung der Netzwerklatenz zuschreiben.