Hallo, in einer Mailingliste für Webentwickler wurde gefragt, welche serverseitige Webtechnologie wohl wieviel Strom verbrauche. Zur Auswahl stehen statische Webseiten mit Apache, NGINX oder Ähnlichen, sowie dynamische Webseiten mit verschiedenen Programmiersprachen und Daten-Backends. Mich interessiert dabei vor allem, wie sich die Daten für solche Auswertungen zuverlässig ermitteln lassen. Als erste Idee würde ich vermutlich einen SBC verwenden und einen Datenlogger in dessen Versorgung klemmen. Bislang hab ich aber keine Idee, welchen Datenlogger ich dazu nehmen kann. Bestenfalls sollte der Datenlogger einen Datenpunkt pro Sekunde messen und aufzeichnen, für eine halbe Stunde Messung genügend Speichertiefe haben, und leicht auslesbar sein. Die Linux-Werkzeuge powertop(8) und powerstat(8) sind mir bekannt, liefern jedoch nicht die Daten, die ich suche. Wenn jemand andere Linux-Werkzeuge kennt, die solche Daten liefern können, freue ich mich ebenfalls. Weiß dazu jemand etwas oder hat womöglich bessere Ideen? Lieben Dank für alle konstruktiven Tipps, Ideen und Hinweise. Frohe Weihnachten!
Du willst an der Steckdose loggen? Diverse Funksteckdosen messen den Strom und können den mit Tasmota-Firmware auch schnell genug raussenden, MQTT z.B. Ansonsten: Schau mal ob dein Server iKVM o.Ä. hat, oft wird da der Stromverbrauch, auch als Graph über längere Zeit, angezeigt. Hängt der Server an einer USV? Auch die könnte den Stromverbrauch anzeigen. Ist natürlich ungünstig, wenn der Server da nicht alleine ist.
Sheeva P. schrieb: > welche serverseitige Webtechnologie wohl wieviel Strom verbrauche. Zur > Auswahl stehen statische Webseiten mit Apache, NGINX oder Ähnlichen, > sowie dynamische Webseiten mit verschiedenen Programmiersprachen und > Daten-Backends. Natürlich brauchen statische Webseiten sm wenigsten Strom, aber wie willst du statisch Dazenbankinhalte anzeigen. Dennoch wird auf den meisten Webseiten viel zu wenig vorausberechnet und viel zu oft content neu generiert. Dem normalen Webentwickler ist scheissegal wie viele Resourcen er verbraucht, da werden dutzend Frameworks übereinandergestapelt bei denen keiner mehr weiss wie die ihre Seiten generieren. Wen wundert die Nachlässgkeit, wenn jedes Kilobyte an Information die zum Kunden übertragen wird wie selbstverständlich mit Megabytes an Werbung und Spionagetrackern ergänzt wird.
Ich habe vor über zehn Jahren mal diverse SAP HANA Appliances gemessen. Dazu habe ich einfache Stromverbrauchsmesser von Conrad zwischen geschaltet und bei verschiedenen Lasten gemessen. Sowas in netzwerkfähig würde ich verwenden. Da die meisten Webserver als virtuelle Maschinen laufen, sollten auf der Hardware auch nur diese Webserver laufen. Es empfiehlt sich sehr, die Maschine vorher mit synthetischen Tests aufs Maximum zu belasten, damit die obere Grenze bekannt ist. Aber nur kurzzeitig, denn dabei stirbt die Hardware gerne mal. Natürlich auch die gebootet Maschine mit allen virtuellen Maschinen im Leerlauf messen. Dann sind die Extremwerte bekannt und die eigentlichen Messungen lassen sich dann gut einordnen und bewerten. Massiven Einfluss hat auch die Konfiguration der Webserver. Das gilt sowohl für die Hardware als auch die Software. Einzelne CPUs durch ungeschickte Anordnung der Einsteckcontroller zu überlasten, geht erheblich auf die Performance. Auch hier verschiedene Konfigurationen mit synthetischen Tests ausprobieren, dann zeigen sich die Bottlenecks recht schnell und können optimiert werden. Verschiedene Firmware-Versionen für die Controller lohnt sich auch noch auszuprobieren. Maßgeblichen Einfluss auf die Performance der Serversoftware hat auch deren Konfiguration. Bei bild.de hatte ich mal das Problem, dass die Speicherauslastung sehr hoch war und die CPUs mit etwa 12% Load vor sich hin idelten. Mit ein paar kleinen Änderungen, wodurch vorgehaltener Prozesse schneller wieder abgebaut wurden, ging dann der Durchsatz dramatisch hoch und ich konnte 50 Server abbauen lassen. Die Software auf dem Webserver lässt sich selbst auch noch mit verschiedenen Compiler Optionen beschleunigen. Ruhig auch mal den ICC von Intel, anstatt des gcc ausprobieren. Der bringt sogar bei AMD CPUs noch erhebliche Gewinne. Auch ohne Grafikkarten als Beschleuniger. Jetzt habe ich ganz schön weit ausgeholt... ;) Grundsätzlich geht es einfach darum, das Maximum an Rechenleistung für den eingesetzten Strom zu bekommen. Dabei wirklich jeden Stein umzudrehen und alles zu benchmarken, lohnt sich sehr. Jedes Detail für sich bringt teilweise nur wenig, in der Summe kommt dann doch so einiges zusammen. Zum Schluss kann das über die Konkurrenzfähigkeit und damit über das weiter Bestehen des Unternehmens entscheiden. Ausfallsicherheit, oft mit Redundanz verwechselt, lässt sich oft mit Software günstiger darstellen als mit Hardware. Aber das würde den von mir sowieso schon gesprengten Rahmen pulverisieren. Das größte Potential sehe ich am Anfang in gut konfigurierter Hardware, was außer Zeit nichts kostet. Die Software selbst zu optimieren bring auch noch mal so richtig was, braucht aber viel Zeit zum Lernen und experimentieren. Wichtig ist, die Software in der Produktion zu testen. Nur da trennt sich die Speu vom Weizen. Viele Grüße, huebi
Michael B. schrieb: > Dem normalen Webentwickler ist scheissegal wie viele Resourcen er > verbraucht, da werden dutzend Frameworks übereinandergestapelt bei denen > keiner mehr weiss wie die ihre Seiten generieren. Auch ein ganz wichtiger Punkt. Frameworks sind die ganz große Pest. Bei PHP zum Beispiel, kostet selbst das einfachste Framework mindestens 90% Leistung. Also lieber von Hand programmieren. Wichtig ist auch ein perfektes Deploimentsystem, damit bei Fehlern auch direkt wieder zurück gerollt werden kann. Viele Grüße, huebi
Lieben Dank für Deine Antwort, und frohe Weihnachten auch Dir! Εrnst B. schrieb: > Du willst an der Steckdose loggen? Ja, entweder vor oder hinter dem Netzteil eines RasPi, OrangePi oder einem ähnlichen SBC. Das hätte den Vorteil, daß bei Seiten mit Datenbank-Backend nicht nur der Webserver, sondern auch die DB eingehen würde, zum Preis von möglicherweise ziemlich viel Zeug, das die Rechner sonst noch machen. Aber natürlich ist das nur eine erste Idee... > Diverse Funksteckdosen messen den Strom und können den mit > Tasmota-Firmware auch schnell genug raussenden, MQTT z.B. MQTT ist eine Möglichkeit, die viele Datenlogger wie die mit Tasmota schon können, aber wenn es was mit Redis, RabbitMQ oder Kafka sein soll... kenne ich. Am Ende sollen die Daten vielleicht in Elastic- oder OpenSearch, oder möglicherweise auch in Jupyter enden. > Ansonsten: Schau mal ob dein Server iKVM o.Ä. hat, oft wird da der > Stromverbrauch, auch als Graph über längere Zeit, angezeigt. > Hängt der Server an einer USV? Auch die könnte den Stromverbrauch > anzeigen. Ist natürlich ungünstig, wenn der Server da nicht alleine ist. Bei meinen Providern kann ich solche Messungen vermutlich vergessen, es sei denn, ich bekomme einen davon dazu, dabei aktiv mitzumachen. Hm, das könnte möglicherweise über die Company interessant sein, lieben Dank für die tolle Inspiration... wenngleich ich bislang fürchte, daß Technologien wie iKVM, iDRAC und Ähnliche da (bisher?) nicht vorhanden sind. Aber die Idee gefällt mir außerordentlich, danke und Dir nochmal frohe Weihnachten!
Michael B. schrieb: > Natürlich brauchen statische Webseiten sm wenigsten Strom, Klar, aber welche? Apache httpd? Nginx? Eigenbauten mit Go(lang) oder Python oder C++ mit dem Wt-Framework? > aber wie willst du statisch Dazenbankinhalte anzeigen. In meinem OP kannst Du ja lesen, daß ich da schon zwischen statischen und dynamischen Seiten unterscheide. Machen wir uns nichts vor: je nach Typus einer Website sind 5 bis 95 Prozent der meisten Seiten dynamisch. Aber vielleicht kann ich hinter ein Wordpress, Magento oder Dingsi mal einen PostgreSQL, MySQL, Elastic- oder OpenSearch oder sonstwas tun und sehen, was dann passiert. Performanceseitig kann ich das ganz gut, das mache ich ja nur seit 25 Jahren, aber was den Strom- bzw. Energieverbrauch angeht? Äh. Ja. Insofern glaube ich: bei 90% der mir bekannten Seiten kann der überwiegende Teil der Seite grundsätzlich statisch erzeugt werden, und Seitengeneratoren wie Hugo oder Lektor können das prima. Den kleinen Teil mit dem Kontaktform oder den größeren Teil mit dem Forum kann man immer noch dynamisch und wenn möglich, mit einem anständigen Caching bauen. > Dennoch wird auf den meisten Webseiten viel zu wenig vorausberechnet und > viel zu oft content neu generiert. Das ist eine andere Geschichte und nicht zuletzt auch darin begründet, daß manche Webentwickler beim Caching vielleicht nicht so fit sind. Die müssen allerdings Sachen wie Bootstrap, ReactJS oder Angular beherrschen und sind deswegen durchaus fit in komplexen Sachen, aber vielleicht nicht gerade in Backend-Technologien -- und ausgerechnet Caching ist eine der mit riesigem Abstand komplexesten davon. There are two hard things in computer science: cache invalidation, naming things, and off-by-one-errors. Auch Dir: Frohe Weihnachten, danke für Deinen Beitrag! :-)
Huebi H. schrieb: > Ich habe vor über zehn Jahren mal diverse SAP HANA Appliances gemessen. Hallo Huebi, lieben Dank für Deinen Beitrag und auch Dir wünsche ich frohe Weihnachten! Er enthielt aber so viele erhellende Aussagen, daß ich gerade nicht darauf antworten kann, dazu komme ich eventuell erst übermorgen. Lieben Dank und laß' es Dir bis dahin gut gehen! :-)
Hallo Huebi, Huebi H. schrieb: > Auch ein ganz wichtiger Punkt. Frameworks sind die ganz große Pest. > Bei PHP zum Beispiel, kostet selbst das einfachste Framework mindestens > 90% Leistung. Naja, das ist am Ende eine Abwägung zwischen Entwickler- und Laufzeit. Wenn ich sehe, daß meine Go-Implementierungen 25.000 Requests pro Sekunden können und meine Python-Implementierungen mit Flask auf derselben Maschine etwa auf 1.800... statische Seiten, wohlgemerkt. Trotzdem unfair. > Also lieber von Hand programmieren. Wichtig ist auch ein perfektes > Deploimentsystem, damit bei Fehlern auch direkt wieder zurück gerollt > werden kann. Ich schreibe beinahe alles von Hand, und mein Deploymentsystem basiert auf Ansible, Traefik, Docker Swarm und einer privaten Docker-Registry. :-)
Schon etwas älter, aber nett zum Durchblättern, wenn man sich für HTTP(s)-Server-Optimierung interessiert: http://nabstreamingsummit.com/wp-content/uploads/2022/05/2022-Streaming-Summit-Netflix.pdf
Den Stromverbrauch fürs Ausliefern einer Website zu messen halte ich für schwierig, vor allem mit so Schätzeisen wie Shelly/Tasmota. Für qualitative Aussagen könnte man sich die CPU-Last ansehen die sehr stark mit dem Stromverbrauch korrelieren dürfte. Dafür gibt es Methoden.
Huebi H. schrieb: > Ruhig auch mal den ICC von Intel, anstatt des gcc ausprobieren. Das liegt auch an Patenten, die gcc nicht zur Optimierung verwenden kann, bzw. warten darf bis diese ausgelaufen sind.
Sheeva P. schrieb: > welche serverseitige Webtechnologie wohl wieviel Strom verbrauche. Zur > Auswahl stehen statische Webseiten mit Apache, NGINX oder Ähnlichen, > sowie dynamische Webseiten mit verschiedenen Programmiersprachen und > Daten-Backends. > Mich interessiert dabei vor allem, wie sich die Daten für solche > Auswertungen zuverlässig ermitteln lassen. "Zuverlässig" auf eine Zahl heruntergebrochen wohl gar nicht. Viel zu groß sind die Einflüsse der konkreten Aufgabenstellung, Implementierung, Hardware, Aufrufverhalten etc. Über eine größere Menge an Applikationen lässt sich hier zumindest ein grober Vergleich finden. Für einen Benchmark daheim genügt es, einfach auf derselben Hardware zu ermitteln wie viele Anfragen pro Sekunde bearbeitet werden können. Genauer wird's nicht. Für die Leistungsstufen halt irgendeine Hausnummer annehmen, wenn du statt deinem Laptop einen Raspberry oder einen Server nimmst, kommen sowieso ganz andere Werte raus. Mit deinem geplanten Setup kommt dann halt raus: - PHP 0,06545 Ws pro Anfrage (-90% +1000%) Nettes Hobby aber vergebene Mühe.
Wenn es nur um den Vergleich der verschiedenen Web-Technologien geht, installier alles auf einem Notebook und mess die Zeit bis der Akku leer ist. Es sollte nur sichergestellt sein, dass nicht bei einem Lauf mal eben Linux/Windows Updates installiert werden :-)
Michael B. schrieb: > Dennoch wird auf den meisten Webseiten viel zu wenig vorausberechnet und > viel zu oft content neu generiert. Das sehe ich auch so. Strom ist halt billiger, als aufwändige Entwicklung. Dazu kommt "personalisierte" Werbung, die meiner Meinung nach überflüssig ist.
:
Bearbeitet durch User
Besonders sinnarm wird es, wenn gering bis mässig belastete Sites nicht jeweils eine auf einem physikalischen Server sitzen, sondern sehr viele zusammen auf Virtualisierung. Da kommt dann zwar über das Hardware-Management raus, dass die gesamte Kiste sagen wir 200W verbrät, aber viel kann man sich von diesem Wert nicht kaufen. Interessant wird das eher bei hoch belasteten Sites. Allerdings ist das dann ein Szenario, das am konkreten Beispiel betrachtet werden muss und nur darüber etwas aussagt. Oben wurde die sehr spezielle Anforderung von Netflix-Streaming en detail betrachtet. Hat man eine stark interaktive Site mit komplexem Datenbank-Backend, sieht die Sache völlig anders aus.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Strom ist halt billiger, als aufwändige Entwicklung. Vor allem aber ist aufwändige Entwicklung sehr langsam, und die Wege zum Ziel sind mit Leichen verreckter Projekte gepflastert.
(prx) A. K. schrieb: > Vor allem aber ist aufwändige Entwicklung sehr langsam, und die Wege zum > Ziel sind mit Leichen verreckter Projekte gepflastert. Projekte verrecken auch mit unaufwändiger Entwicklung, denn man meint dann, es mit besonders ahnungslosen Leuten hinzubekommen, dank Scrum kann man ja einfach die Ziele so weit herunterschrauben bis das Ergebnis zum miesen Fortschritt der Ahnungslosen passt. Aber es ist gut, dass sicv hier jemand überhaupt Gedanken macht, aber ich fürchte vergeblich wenn die auf 0.1Wh reduzierte Webseite auf die Gier von Werbetreibenden und Marketingfuzzies trifft.
Michael B. schrieb: > Projekte verrecken auch mit unaufwändiger Entwicklung Aber viel schneller. Grossprojekte werden aufgrund der bereits getätigtem Investition und der Anzahl Beteiligter erst abgeschossen, wenn sich eines Tages bei allen der Eindruck durchgesetzt hat, es sei wirklich nichts mehr zu retten. Vorher schüttet man lieber noch mehr Geld rein. Niemand will der Erste sein. > wenn die auf 0.1Wh reduzierte Webseite auf die > Gier von Werbetreibenden und Marketingfuzzies trifft. Nur entstehend die Stromkosten dann hauptsächlich am anderen Ende. Daher wäre eine andere Zahl interessant, nämlich der Gesamtstromverbrauch einer Site einschliesslich der sie nutzenden Clients.
:
Bearbeitet durch User
Ein gewisser Teil laesst sich mit den Datenbankabfragen machen. Macht man Select * from .. where ... und laesst sich alles geben, um's mit dem Script aufzuarbeiten oder laesst man sich nur das benoetigte geben. Allenfalls zieht man zu viel ueber das Netzwerk.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.