Green Coding: Da optimieren, wo es am meisten bringt!

Ausgehend von der CO₂-Challenge haben wir uns mit der Frage beschäftigt, wie wir den Energieverbrauch unserer Software reduzieren können. Als Fallbeispiel haben wir eine intern entwickelt und genutzte Webanwendung zur Erzeugung von Mitarbeiterprofilen analysiert. Die Anwendung läuft auf einem Server am Standort Karlsruhe (on-premise). 

Analyse des Stromverbrauchs des Servers

Als erstes messen wir den Stromverbrauch des Servers, auf dem unsere Anwendung läuft. Für die Messung haben wir jeweils ein Strommessgerät vom Typ Voltcraft SEM5000 an die beiden Netzteile des Servers in Karlsruhe für mehrere Wochen angeschlossen.

Wir haben uns den Vergleich des Energieverbrauchs nach Stunde über alle Wochentage angeschaut. Da auf dem Server neben der untersuchten Anwendung noch weitere Anwendungen laufen, war uns schon vorher klar, dass wir den genauen Stromverbrauch nicht isoliert messen können. Wir hatten dennoch erwartet, werktags zu den typischen Arbeitszeiten einen Anstieg im Energieverbrauch zu sehen. Stattdessen scheint der Energieverbrauch die meiste Zeit konstant zu sein mit Ausnahme von Peaks zu Backupzeiten am Wochenende und in den frühen Morgenstunden.

Die erste Erkenntnis für uns ist damit, dass wir mit der einen Strommessung nicht weit kommen, bzw. diese nicht als einzigen Input dienen kann, da es daraus schwierig ist irgendwelche Maßnahmen abzuleiten.

Analyse mittels HTTP Access Logs

Als nächstes haben wir uns die HTTP Access Logs der Anwendung angeschaut. HTTP Access Logs zeichnen alle Anfragen auf, die auf das Backend einer Webanwendung gemacht werden. Indem wir sie analysieren, erhalten wir Informationen über das Nutzerverhalten und die Menge der übertragenen Daten. Daraus können wir den Energiebedarf abschätzen und Maßnahmen zur Reduktion ableiten.

HTTP Access Logs lassen sich i.d.R. sehr einfach „anschalten“, für eine Spring Boot Anwendung sind beispielsweise nur wenige Spring Properties nötig.  Eine Log-Zeile enthält Informationen wie Anfragezeitpunkt, URL des Aufrufs, Antwortgröße in Bytes oder Ausführungsdauer (vgl. Abbildung). Für eine schnelle Visualisierung haben wir GoAccess [GoAccess] verwendet.

Die Auswertung der Logs bezieht sich auf den Zeitraum 01. Juli 2025 bis 04. August 2025. In diesem Zeitraum gab es insgesamt 319.860 Zugriffe und 17,68 GiB an übertragenen Daten.

Aus den HTTP Access Logs lassen sich gut die Hauptnutzungszeiten einer Anwendung ableiten. Wie in der Abbildung unten erkennbar, wird sie hauptsächlich werktags zwischen 07:00 Uhr und 18:00 Uhr verwendet. Darüber hinaus wird die Anwendung mit durchschnittlich ca. 4000 Aufrufen pro Tag insgesamt eher wenig genutzt.

Durch die geringe Nutzung ist es weniger überraschend, dass die häufigste Anfrage (57%) nicht von Endnutzer:innen, sondern vom Prometheus-Monitoring (/actuator/monitoring) stammt. Die größte Datenmenge (4 GB) wurde durch Profilbilder übertragen. Manche der Anfragen werden innerhalb einer Session mehrfach abgefragt, liefern aber Daten, die sich selten ändern. Mit geeignetem Caching ließen sich hier Aufrufe sparen.

Erste Maßnahmen und deren Auswirkungen

Prometheus wurde zu Untersuchungszwecken eingebaut, wird aber nicht mehr zum Monitoring der Anwendung genutzt, da dafür mittlerweile andere Tools genutzt werden. Daher haben wir uns in Abstimmung mit dem Entwicklungsteam dafür entschieden, Prometheus abzuschalten. Uns hat vor allem interessiert, ob die Abschaltung eine messbare Auswirkung auf den Stromverbrauch hat. Dazu haben wir uns erneut die Ergebnisse der Strommessung angeschaut und die Werte vor und nach der Abschaltung verglichen. Das Ergebnis ist in der Abbildung unten abgebildet. Tatsächlich wurde der durchschnittliche Energieverbrauch des Servers durch die Abschaltung von 100,6 Wh auf 96,4 Wh reduziert (signifikant laut t-Test mit p=0,000070 und α=0,05). Das sind zwar nur 4,2 %, akkumuliert über ein Jahr spart man damit aber immerhin – mit sehr geringem Aufwand – bereits 37,287 kWh. Zum Vergleich: Eine moderne Waschmaschine benötigt ca. 0,5 kWh pro Waschgang, ein Elektroauto ca. 15 kWh für 100 km.

Das Entwicklungsteam hatte bereits kurz nach Beginn unserer Messungen die Profilbilder verkleinert. Bei der Mitarbeiterliste werden jetzt pro Seitenaufruf ungefähr 2 MB weniger Daten übertragen, was einer Reduktion um ca. 51% entspricht. Im Stromverbrauch des Servers konnten wir dadurch in diesem Fall keinen signifikanten Unterschied feststellen. Da die untersuchte Anwendung nicht die einzige Anwendung auf dem Server ist und zudem wenig genutzt wird, hat uns das nicht überrascht. An anderer Stelle des Übertragungsweges, beispielsweise auf dem Endgerät der Nutzerin, kann die Energieeinsparung stärker ins Gewicht fallen.

Wieviel Energie pro übertragenem MB tatsächlich nötig ist, lässt sich nur schwer sagen. In einer Studie [Studie] wurde ein Verbrauch von ungefähr 0,06 Wh pro übertragenem MB ermittelt. Im Folgenden nehmen wir diesen Wert als Referenz. Die Mitarbeiterübersicht wird pro Monat 110-mal aufgerufen. Damit ergibt sich eine Einsparung von 220 MB im Monat, was 13,2 Wh Einsparung bedeutet. Zur Einordnung: Die Energiemenge von 10 - 15 Wh entspricht ungefähr einer Aufladung eines Smartphone Akkus oder der Bewegung eines E-Autos um ca. 50m - 75m (Annahme 20kWh/100km).

Ein Blick in die Serverauslastung

Wer kein Strommessgerät zur Hand hat, kann auch die CPU-Auslastung eines Servers als Näherung des Stromverbrauchs verwenden. Je höher die Auslastung ist, desto mehr Strom wird in der Regel benötigt. Allerdings ist das Verhältnis nicht linear. Das haben wir auch über einen Lasttest für unseren Server geprüft (vgl. Abbildung). Da ein Server bereits im “Idle”-Zustand eine relevante Menge an Strom benötigt, ist es effizienter, eine Instanz möglichst auszulasten, anstatt mehrere mit geringerer Auslastung zu betreiben.

Die CPU-Auslastung unseres Servers lag auch schon vor der Abschaltung von Prometheus die meiste Zeit deutlich unter 50%. Pluto liegt häufig bei weniger als 1%, ebenso die anderen Anwendungen, die noch auf dem Server laufen. Zum Vergleich: Das Prometheus-Monitoring verursachte mehr als 10% CPU-Auslastung, teilweise auch deutlich mehr.

Fazit

Es ist nicht trivial abzuschätzen, durch welche Maßnahmen der Energieverbrauch einer Software am meisten reduziert werden kann. Der Blick fürs Ganze ist wichtig. Für unsere Anwendung konnten wir über die HTTP Access Logs zwar noch weitere Maßnahmen ableiten. Solange die Anwendung aber nur einen geringen Anteil der Gesamtauslastung des Servers beisteuert und dieser darüber hinaus bereits eine relativ geringe Auslastung hat, bleibt zumindest das serverseitige Stromsparpotential gering. In unserem Falle sehen wir das größte Einsparpotential durch eine Cloud-Migration von Pluto und der restlichen Anwendungen unseres Servers. Diesen könnten wir dann nämlich abschalten und dadurch ca. 400 kWh jährlich sparen. Dadurch wird der Energiebedarf zwar nur verlagert, allerdings laufen Anwendungen in der Cloud i.d.R. energieeffizienter. Darüber hinaus können Ressourcen dort leichter dynamisch skaliert werden und Anwendungen außerhalb der Nutzungszeiten sogar komplett “abgeschaltet” werden. 

Links:

CO₂-Challenge: https://co2-challenge.de

GoAccess: https://goaccess.io

Studie: https://onlinelibrary.wiley.com/doi/full/10.1111/jiec.12630