Von Verfluchtnochmal_5987108 am Mi, 16. Oktober 2019 um 15:35 #
Natürlich reicht die durchschnittliche CPU Last am Cluster denn nur die zählt und nicht die 0.5 Prozent Ausreißer die auf einem Liniendiagramm noch nicht mal zu sehen sind weil die für den gesamten Energieverbrauch schlichtweg keine Rolle spielen
Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
... in diesem Zusammenhang reichlich wenig, denn - wie ich ja bereits schrieb - muss man die Last (auch / vor Allem) bezüglich des Volumens der verschlüsselt übertragenen Daten normieren. Haben Sie das berücksichtigt?
Zudem lässt sich von einer unveränderten Durchschnittslast (Über welche Definition von "Durchschnitt" reden wir eigentlich? Pro Zeitintervall gemessene Last durch diskretisierte Zeitdifferenz/Zeitintervallänge bzw. Messdauer?) nur bedingt auf die zeitliche Verteilung jener Last, bzw. der sie verursachenden Requests (Anzahl & Volumen) schließen. Die zeitlich integrierte Lastverteilung (nennen wir sie doch Lastsumme mit der Einheit Last mal Zeit) kann für zwei verschiedene Lastverteilungen die selbe sein. Hinter Ihren Daten können sich also verschiedene Lastverteilungen verstecken. Wie haben Sie gemessen? Über welche Dauer? Mit welcher Messauflösung?
Unabhängig davon arbeitet Hardware bei einer vorgeschriebenen "Lastsumme" (Definition s.o.) für gewöhnlich weitaus effizienter, wenn diese als konstante Lastverteilung statt mit kurzzeitig stark variierender Spitzenlasten anliegt. Denn so liegt die Rechenleistung der Hardware nicht brach (Hardware braucht auch im Idle Strom), die Hardware muss nicht wild zwischen Lastszenarien wechseln (kostet Zeit in Form von Rechenzyklen und Energie), und sie muss nicht ganz so hoch takten (Energiebedarf steigt üblicherweise superlinear oder überproportional mit dem Takt). Demnach können unterschiedliche Lastverteilungen bei gleicher "Lastsumme" unterschiedlichen Energiebedarf wecken. Oder können Sie diese Effekte anderweitig ausschließen?
Also lässt sich Ihre Aussage über die Irrelevanz von Verschlüsselung bezüglich der Durchschnittslast bzw. der daraus resultierende Energiebedarf auf der Grundlage dieser Daten nicht belastbar belegen. Es ist komplizierter als Sie hier zu verstehen geben. Ihre Ausführungen sind zu einfach.
Und angenommen, Ihre Aussage wäre korrekt, ließe sich daraus schlussfolgern, dass der durch Verschlüsselung zusätzlich anfallende Rechenaufwand keinen zusätzlichen Energiebedarf wecken würde. Das wäre wissenschaftlich nicht plausibel nachvollziehbar (Perpetuum mobile lässt grüßen!).
Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 01:04 #
Wenn man so gar keine Ahnung wie du hat weiss man natürlich nicht dass die Datenmenge sekundär ist denn der hauptsächliche overhead bei https liegt im Handshake während dir aes-ni zwischen 2500 und 3000 MB pro Sekunde verschlüsselt (Megabyte, nicht Mbit)
Es ist nicht komplizierter, der cluster zeichnet ein Liniendiagramm mit der durchschnittlichen CPU last aller VM's auf allen nodes in MHz
Und nein, es ist nicht sehr wahrscheinlich dass genau am selben Tag wo man alles auf https umstellt nach 5 Jahren die Zugriffe auf alle Kundeseiten zufällig gewaltig einbrechen und den von dir behaupteten Anstieg der Last durch die Verschlüsselung zufällig verstecken
Natürlich wird es ein paar Rechenzyklen brauchen aber nicht signifikant sonst hätten wir 2018 nach Spectre/Meltdown und 2 Monate nach Umstellung auf https nicht bei der neuen Hardware nichtsschlicht und ergreifend die CPUs halbiert weil nach PHP7 zweijJahre zuvor die Hardware nur Däumchen gedreht hat
Wenn du dämlich recht hättest wäre der neue Cluster physisch gleich stark geblieben und wir hätten uns darüber gefreut dass die Optimierungen der letzten beiden Jahre Ressourcen für https frei geschaufelt haben, war aber nicht der Fall und ja der Austausch war seit 2015 geplant
Natürlich reicht die durchschnittliche CPU Last am Cluster denn nur die zählt und nicht die 0.5 Prozent Ausreißer die auf einem Liniendiagramm noch nicht mal zu sehen sind weil die für den gesamten Energieverbrauch schlichtweg keine Rolle spielen
Wenn die durchschnittliche Anzahl Requests und Traffic unverändert sind und du von einem Tag auf den anderen knapp 1000 domains auf https umstellst und sich in der durchschnittlichen Last auf der darunter liegenden Hardware nichts ändert was schliesst du daraus?
Zudem lässt sich von einer unveränderten Durchschnittslast (Über welche Definition von "Durchschnitt" reden wir eigentlich? Pro Zeitintervall gemessene Last durch diskretisierte Zeitdifferenz/Zeitintervallänge bzw. Messdauer?) nur bedingt auf die zeitliche Verteilung jener Last, bzw. der sie verursachenden Requests (Anzahl & Volumen) schließen. Die zeitlich integrierte Lastverteilung (nennen wir sie doch Lastsumme mit der Einheit Last mal Zeit) kann für zwei verschiedene Lastverteilungen die selbe sein. Hinter Ihren Daten können sich also verschiedene Lastverteilungen verstecken.
Wie haben Sie gemessen? Über welche Dauer? Mit welcher Messauflösung?
Unabhängig davon arbeitet Hardware bei einer vorgeschriebenen "Lastsumme" (Definition s.o.) für gewöhnlich weitaus effizienter, wenn diese als konstante Lastverteilung statt mit kurzzeitig stark variierender Spitzenlasten anliegt. Denn so liegt die Rechenleistung der Hardware nicht brach (Hardware braucht auch im Idle Strom), die Hardware muss nicht wild zwischen Lastszenarien wechseln (kostet Zeit in Form von Rechenzyklen und Energie), und sie muss nicht ganz so hoch takten (Energiebedarf steigt üblicherweise superlinear oder überproportional mit dem Takt).
Demnach können unterschiedliche Lastverteilungen bei gleicher "Lastsumme" unterschiedlichen Energiebedarf wecken.
Oder können Sie diese Effekte anderweitig ausschließen?
Also lässt sich Ihre Aussage über die Irrelevanz von Verschlüsselung bezüglich der Durchschnittslast bzw. der daraus resultierende Energiebedarf auf der Grundlage dieser Daten nicht belastbar belegen. Es ist komplizierter als Sie hier zu verstehen geben. Ihre Ausführungen sind zu einfach.
Und angenommen, Ihre Aussage wäre korrekt, ließe sich daraus schlussfolgern, dass der durch Verschlüsselung zusätzlich anfallende Rechenaufwand keinen zusätzlichen Energiebedarf wecken würde. Das wäre wissenschaftlich nicht plausibel nachvollziehbar (Perpetuum mobile lässt grüßen!).
Wenn man so gar keine Ahnung wie du hat weiss man natürlich nicht dass die Datenmenge sekundär ist denn der hauptsächliche overhead bei https liegt im Handshake während dir aes-ni zwischen 2500 und 3000 MB pro Sekunde verschlüsselt (Megabyte, nicht Mbit)
Es ist nicht komplizierter, der cluster zeichnet ein Liniendiagramm mit der durchschnittlichen CPU last aller VM's auf allen nodes in MHz
Und nein, es ist nicht sehr wahrscheinlich dass genau am selben Tag wo man alles auf https umstellt nach 5 Jahren die Zugriffe auf alle Kundeseiten zufällig gewaltig einbrechen und den von dir behaupteten Anstieg der Last durch die Verschlüsselung zufällig verstecken
Natürlich wird es ein paar Rechenzyklen brauchen aber nicht signifikant sonst hätten wir 2018 nach Spectre/Meltdown und 2 Monate nach Umstellung auf https nicht bei der neuen Hardware nichtsschlicht und ergreifend die CPUs halbiert weil nach PHP7 zweijJahre zuvor die Hardware nur Däumchen gedreht hat
Wenn du dämlich recht hättest wäre der neue Cluster physisch gleich stark geblieben und wir hätten uns darüber gefreut dass die Optimierungen der letzten beiden Jahre Ressourcen für https frei geschaufelt haben, war aber nicht der Fall und ja der Austausch war seit 2015 geplant