In meinem letzten Artikel zur Auswertung globaler Zertifikatslog war unter anderem ein Screenshot zu sehen, der die Systembelastung des für die Durchführung der Tests benutzten Raspberry Pi darstellte.

Diese Ergebnisse brachten mich dazu, diese Analysen nicht ständig laufen zu lassen - denn abgesehen vom gestiegenen Energiebedarf lag die Temperatur meines passiv gekühlten Pi dabei auch gerne mal über 70 Grad Celsius. Das ist eine Temperatur, die ich einem Gerät nicht gestatte, wenn ich nicht im Haus oder zumindest auf dem Grundstück bin.

Dazu kommt noch, dass dieser spezielle Anwendungsfall - was die Last angeht - schwer abzuschätzen ist: Da die Anzahl der im Strom auftretenden Zertifikate sehr stark schwankt kann es sein, dass diese 70 Grad Celsius noch nicht das Maximum darstellen.

Daher hatte ich schon längere Zeit vor, dem Mysterium der hohen Auslastung nachzugehen und idealerwese Mittel und Wege zu finden, sie abzustellen. Dazu nahm ich mir nunmehr die Zeit. Zunächst wollte ich feststellen, was genau eigentlich für diese extrem hohe Last sorgt.

Die Anwendung arbeitet derzeit so, dass die Daten im Strom empfangen und aufbereitet werden, danach werden die einzelnen Datensätze analysiert, aufbereitet und nachdem das Ranking berechnet wurde an InfluxDB weitergeleitet. All das geschieht in dem aktuell von mir dazu bnutzten Python-Progrämmchen in einem Callback. Aktuell führt das dazu, dass auf dem Pi in top eine Prozessorlast von 100% für python3 gelistet wird. Daher schaltete ich den Callback komplett aus - das führte zu einem Wert von 98% in top.

Völlig überraschend für mich war also keineswegs mein Code zur Auswertung und Speicherung schuld - sondern de Code, der den Stream entgegennahm und aufbereitete, um dann die einzelnen Daten anden Callback zu geben.

An diesem Punkt experimentierte ich weiter - schließlich ist Python nicht die einzige Möglichkeit der Anbindung zur Konsumierung des Zertifikats-Stroms: andere Möglichkeiten sind Java, Go und Javascript. Ich testete Go und Java, weil - sind wir doch mal ehrlich: Javascriopt? ewww!.

Diese Tests fanden nicht mehr auf dem Pi statt, da das Installieren neuer Anwendungen dort ganz schön zur Geduldsprobe verkommen kann. Statt dessen führte ich den Test mit dem abgespeckten Python Programm ohne Callback nochmals auf einem PC (Ubuntu Linux 18.04) durch und stellte das Ergebnis entsprechenden Implementierungen in Go und Java gegenüber. Das Ergebnis sieht man in der untenstehenden Tabelle:

Damit hatte ich deutliche Hinweise, auch wenn die Messungen ungenau und mit großer Unsicherheit beaufschlagt waren, ließ sich für mich ein klarer Trend ablesen, der es rechtfertigte, nun doch Go auf dem Raspi zu installieren und zu sehen, wie sich das Testprogramm dort schlagen würde.

Leider wurde meine Hoffnung nicht erfüllt - auf dem Pi listete top das Go-Programm immer noch mit ungefähr 40% Last (stark schwankend), so dass aus meiner Sicht (vor allem, da sämtliche Auswertung noch fehlte und ich ein völliger Go-Neuling bin) die Umstellung des Programms zur ständigen Überwachung des CertStream nicht lohnte. Interessant war in diesem Zusammenhang noch, dass

vcgencmd measure_clock arm

nur sehr selten das mögliche Maximum der Taktfrequenz anzeigte: meistens dümpelte diese bei 600MHz herum. Das erklärt eventuell auch die Tatsache, dass ein inzwischen über 12 Jahre alter Centrino-Laptop bei der Ausführung des Go-Programms lediglich eine Auslastung von 15% in top erreichte.

Das reichte trotzdem aus, zu versuchen ob dieser alte Laptop vielleicht das Mittel der Wahl sein könnte, den CertStream kontinuierlich zu überwachen. Ich benutzte für diesen Test das bereits vorhandene Python-Programm und musste leider erkennen, dass auch das keine Option ist - bei Benutzung von Pythen steigt die Auslastung lat top auf zwischen 60 und 70% an und der Lüfter ist kontinuierlich hörbar. Ein solcher Stress ist für über 12 Jahre alte Teile höchstwahrscheinlich nicht gut, daher brach ich den Test nach einem halben Tag wieder ab.

Artikel, die hierher verlinken