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