Re: Performance Anomalie
Guten Tag.
Schöke, Karsten - 07.12.25, 11:15:55 CET:
> danke für das schnelle Feedback.
> Natürlich war ursächlich ein "normaler" Workload.
> Aber dieses komplexe Script hat Laufzeitunterschiede innerhalb der
> Betriebssysteme. Hier wird mehrfach via curl u.a. etwas abgefragt und
> die Laufzeit analysiert. Bei Herunterbrechen viel uns auf, das schon
> ein einziger localer curl Aufruf Zeitunterschiede brachte.
Nunja, die von Dir geposteten Aufrufe haben durch das einfache
„--version“-Argument meiner Vermutung nach vor allem die Zeit für das
Forken eines neuen Prozesses inklusive allem, was dazu gehört, gemessen.
Und die Unterschiede von jeweils circa 3 Sekunden zwischen den
Versionsaufrufen für Curl in Debian 11, 12 und 13 beziehen sich auf 1000
Aufrufe.
Ruft euer Skript wirklich tausende Male Curl auf?
> Wir rätseln, woher das in den unterschiedlichen Debian Versionen
> herkommen kann und ob wir hier vielleicht Konfigurationen nicht richtig
> gesetzt haben.
>
> Daher der einfache Test mit den original Docker Containern, welcher ja
> schon Unterschiede aufzeigt, und wir nicht verstehen.
Hoho, das kann sehr viele unterschiedliche Ursachen haben.
Unterschiedliche Curl-Versionen, unterschiedliche Versionen der
verwendeten Bibliotheken, neuere Crypto-Standards im Falle von TLS-
basierten Curl-Aufrufen, neuerer Kernel usw. usf. Im Fall von Netzwerk-
Abfragen auch Änderungen an der Netzwerkverbindung zwischen Quelle und
Ziel.
Ich glaube, wenn ihr da an die Ursache herankommen wollt, müsst ihr die
betreffen Curl-Aufrufe Schritt für Schritt instrumentieren. D.h. mit den
verschiedenen Tracing-Möglichkeiten wie BPF-Tracing im Kernel arbeiten.
Natürlich braucht es dann auch das Verständnis für die anzeigten Werte,
insbesondere bei einem Herunterbrechen der Zeiten auf einzelne System-
Aufrufe oder sogar noch feiner. Ich halte selbst Linux-Performance-Kurse
und halte so eine Analyse dennoch für einigermaßen herausfordernd.
Ein erster Anlauf-Punkt, um sich darüber klar zu werden, wie ein mögliches
Vorgehen aussehen könnte, kann die Webseite von Brendan Gregg geben¹. Von
ihm gibt es mehrere Blog-Posts von solchen Analysen auf dieser Ebene. Oder
auch sein exzellentes BPF Performance Tools Buch. Idealerweise würde ich
während der Messung auch noch auf System-Ebene beobachten, was da
passiert. Das geht in Richtung des aktiven Benchmarkings anstatt nur
passiv auf Ergebnisse zu warten und dann nicht zu verstehen, wie diese
zusammen kommen. Stattdessen zumindest mal mit Atop und ähnlichen
Werkzeugen das System beobachten, während der Benchmark läuft. Im
einfachsten Fall wäre ein Engpass bezüglich einer Metrik erreicht. Dann
ließe sich der Curl-Aufruf und was immer sonst noch für eure Performance-
Betrachtungen eine Rolle spielt diesbezüglich genauer analysieren.
Aber selbst falls ihr es herausfindet, was die Ursache ist… bedeutet das
noch lange nicht, dass sich diese einfach beheben lässt. Und es können
leicht auch mehrere Ursachen sein. Nicht immer kann etwas durch andere
Optionen behoben werden. Auf Verdacht könnt ihr natürlich die
entsprechenden Veröffentlichungshinweise für die unterschiedlichen Curl-
Versionen und Versionen dazwischen durchgehen, inwiefern Curl mittlerweile
unterschiedliche Optionen standardmäßig aktiv hat. Aber möglicherweise
fand die entscheidende Änderung in einer Bibliothek statt, die Curl
verwendet, oder im Kernel.
So oder so: Es könnte ziemlich aufwendig werden, das genau heraus zu
finden. Daher bleibt letztlich die Frage, inwiefern es vielleicht
effektiver ist, etwas an eurem Skript zu ändern, um die beobachten
Performance-Verluste zu kompensieren.
Das mal in aller Kürze dazu.
[1] https://www.brendangregg.com/
Grüße,
--
Martin
Reply to: