Green IT - Enterprise Lab

Green IT
PAWI Dokumentation
Abbildung 1 Titelbild Green IT (Quelle: http://www.ilmforum.de/wpcontent/uploads/2010/12/greenit2.jpg)
Hochschule Luzern – Technik &
Architektur
Informatik - ICT Business Solutions
Benjamin Suter, Elias Stocker
Horw, 23.12.2011
Seite 1 von 53
Inhalt
Management Summary .......................................................................................................... 3
1
Einleitung............................................................................................................................ 4
2
Green IT .............................................................................................................................. 5
2.1
Hintergrund von Green IT ......................................................................................... 5
2.2
Hardware.................................................................................................................... 7
2.3
Software.................................................................................................................... 11
3
Messungen ...................................................................................................................... 15
3.1
Ziele ........................................................................................................................... 15
3.2
Versuchsaufbau Hardware .................................................................................... 16
3.3
Versuchsaufbau Software ...................................................................................... 17
3.4
Erwartung ................................................................................................................. 20
3.5
Messmethode .......................................................................................................... 21
3.6
Versuchsablauf ........................................................................................................ 21
4
Resultate der Messungen .............................................................................................. 25
4.1
Szenario 1 ................................................................................................................. 25
4.2
Szenario 2 ................................................................................................................. 25
4.3
Szenario 3 ................................................................................................................. 26
4.4
Szenario 4 ................................................................................................................. 27
4.5
Szenario 5 ................................................................................................................. 28
5
Auswertung der Messungen ......................................................................................... 29
5.1
Vergleich Erwartungshaltung gegenüber Messresultate .................................. 29
5.2
Gegenüberstellung der Szenarien ........................................................................ 29
5.3
Resultate kritisch analysieren ................................................................................. 31
6
Erweiterte Messungen .................................................................................................... 33
6.1
Erwartungshaltung .................................................................................................. 33
6.2
Messaufbau.............................................................................................................. 34
6.3
Messanalysen........................................................................................................... 36
6.4
Auswertungen.......................................................................................................... 44
7
Fazit ................................................................................................................................... 46
8
Glossar .............................................................................................................................. 48
9
Abbildungsverzeichnis ................................................................................................... 49
10
Tabellenverzeichnis ..................................................................................................... 50
11
Literaturverzeichnis ..................................................................................................... 51
Seite 2 von 53
Management Summary
Since 2008 when Gartner placed the term „Green IT“ on the top of his Hype Cycle,
this word was in every mouth. Green IT becomes a known term in IT and the business.
This paper deals with the aspect of Green IT whether software (operating system,
server software, applications) has an impact on the power consumption of IT
infrastructure. Especially it’s the goal to measure the power consumption of a
.NET/MSSQL based as well as of a PHP/MySQL based Content Management System
(CMS). After measuring the power consumption of Windows Server 2008 R2 and
Ubuntu Server 11 in different scenarios the results were compared. During a measure
period the webserver was penetrated with a stress tool.
There is no difference between Ubuntu and Windows in power consumption in the
idle mode. The power efficiency of the PHP/MySQL based CMS Joomla is better than
the power efficiency of the .NET/MSSQL based CMS DotNetNuke. After analyzing the
absolutely power consumption of any scenario with its answer times it was possible to
bring these results in relation. It’s a good advice to benchmark your own CMS in
order to be aware of its power consumption.
Seite 3 von 53
1 Einleitung
Das Projektmodul „PAWI“ an der Hochschule Luzern Technik und Architektur
beinhaltet ein Informatikprojekt mit einer definierten Aufgabenstellung. Der
Arbeitstitel „Green IT“ für das Projekt steht unter folgenden fachlichen
Schwerpunkten: IT-Infrastruktur, Rechenzentren, Interdisziplinarität.
Die allgemeine Aufgabenstellung befasst sich mit der Fragestellung, ob der
Energieverbrauch der IT-Infrastruktur abhängig von der Software (Betriebssystem,
Serversoftware, Applikation) ist. Die Abhängigkeit von Software auf den
Energieverbrauch wird in der folgenden Arbeit im Bereich von Webservern
gemessen, da der Auftraggeber Manfred Jehle ein eigenes, auf .NET basiertes, CMS
betreibt. Dabei wird zu Beginn der Stromverbrauch der beiden Betriebssysteme
Windows Server 2008 R2 und Ubuntu Server 11 miteinander verglichen. Aufbauend
auf dem Betriebssystem wird jeweils eine unterschiedliche Technologie in den
Messszenarien genutzt. Der Windows Server wird mit Microsoft IIS, Microsoft SQL und
ASP.NET betrieben, der Ubuntu Server mit Apache, MySQL und PHP. Die eigentliche
Aufgabenstellung beinhaltet die Gegenüberstellung der Content Management
Systeme (CMS) DotNetNuke und Joomla. Diese Gegenüberstellung soll zeigen, ob ein
CMS, wie vom Auftraggeber erwartet, Einfluss auf den Stromverbrauch hat und wie
dieser Einfluss bei den beiden CMS mit unterschiedlichen Plattformen ausfällt. Dabei
werden die Caching-Mechanismen der Webservertechnologien und CMS ausser
Betracht gelassen.
Der Aufbau der Arbeit ist so gegliedert, dass zu Beginn der Begriff Green IT erklärt
wird. Anschliessend werden Messungen durchgeführt, die den Stromverbrauch von
definierten Szenarien messen. Die Resultate der Messungen werden kritisch analysiert
und ausgewertet. Mithilfe von erweiterten Messungen werden die Messresultate der
definierten Szenarien verifiziert oder neue Erkenntnisse erlangt. Den Abschluss der
Arbeit bildet ein Fazit mit einer gesamten Auswertung über alle Messungen.
Seite 4 von 53
2 Green IT
“Green with IT, Green in IT” - diese zwei Aspekte stehen hinter dem Begriff Green IT.
Generell umfasst Green IT die ressourcen- und umweltschonende Nutzung von IT
Infrastruktur über den gesamten Lebenszyklus. Dazu gehören die Energieeffizienz bei
Produktion und Nutzung von Hardware sowie die Materialeffizienz (verwendete
Materialien und Produktionsmittel).
Doch wie anfangs des Absatzes erwähnt, gibt es zwei verschiedene Ansätze bei der
Energieeinsparung.


„Green in IT“ bedeutet die energieeffiziente Nutzung von IT Infrastrukturen.
„Green with IT“ beinhaltet die Emissionsreduzierung durch Anwendung von IT.
Heutzutage ist klar, dass IT nicht nur Energie verbraucht, sondern viel zur Verringerung
von CO2 Emissionen beitragen kann. Smart Grid, Smart Building oder Smart Motors
sind nur einige Stichworte im Bereich „Green with IT“. Im folgenden Dokument wird
auf „Green in IT“, also die energieeffiziente Nutzung von IT Infrastrukturen,
eingegangen.
2.1 Hintergrund von Green IT
Die Informationstechnologie (IT) hat sich in den letzten Jahren enorm entwickelt und
ist in der heutigen privaten und beruflichen Welt nicht mehr Weg zu denken. Die
Datenverarbeitung wird komplexer, die Datenmengen grösser, der Datenaustausch
weiträumiger und vernetzter. Das Anbieten und Nutzen solch komplexer
Informations- und Kommunikationssysteme benötigt eine Menge Energie in Form von
Strom. Gemäss einer Studie des Marktforschungsinstituts Gartner (Pettey, 2007) haben
alle Rechenzentren der Welt einen Anteil von rund zwei Prozent der globalen CO2Emmissionen. Dies entspricht ungefähr dem CO2-Ausstoss des weltweiten
Flugverkehrs.
Der Begriff Green IT entwickelte sich in den frühen 1990er Jahren. Als sich Computer
damals vor allem in Verbindung mit Internet in der Gesellschaft ausbreiteten und ITFirmen wie Microsoft grosse Rechenzentren schufen, begann man sich mit dem
Problem der Ressourcenverschwendung im IT-Bereich zu befassen. 1992 führte die
USA die ersten verbindlichen Richtlinien im Zusammenhang mit Green IT ein. (JSProjects UG, 2011)
In den folgenden Jahren wurde dem Thema Green IT lange keine grosse Beachtung
geschenkt. Im Jahr 2008 wurde Green IT in der jährlichen Erhebung der IT Trends von
Gartner als der grosse kommende Hype angepriesen. Heute, drei Jahre später,
scheint es, als sei der Hype bereits wieder vorbei. Cloud Computing soll alle Probleme
lösen. Leider wird das Problem der Ressourcenverschwendung auf diese Weise nicht
gelöst, sondern dem Outsourcing-Partner „abgeschoben“. Der laufend wachsende
Bedarf an Rechenleistung zieht auch einen steigenden Bedarf an Energie mit sich.
Eine Studie des Frauenhofer-Instituts (Holzmann, 2011) besagt, dass sich der
Energieverbrauch bis ins Jahr 2010 verglichen mit dem Basisjahr 2007 um 20% steigern
Seite 5 von 53
wird. Das Thema Green IT ist alles andere als erledigt. Auch die Politik hat sich in den
letzten Jahren vermehrt damit beschäftigt.
2.1.1 Energiepolitik in der Schweiz
In der Schweiz gibt es verschiedene Bestrebungen, den Energieverbrauch nachhaltig
zu verringern. Mit der 2000-Watt- und der 1 Tonne CO2-Gesellschaft hat die ETH
Zürich im Jahr 2008 der Öffentlichkeit eine neue Energiestrategie vorgestellt. Die
Reduktion des CO2 Ausstosses steht dabei im Mittelpunkt. In der folgenden Grafik ist
das Endziel im Jahre 2150 ersichtlich.
Abbildung 2 2000 Watt-Gesellschaft (Novatlantis)
Weiter beschäftigt sich die Schweizer Politik aktuell mit dem Atomausstieg. Der
Wandel bei der Energieerzeugung wird in der IT spürbar sein, weil circa 10 Prozent
des schweizerischen Stroms für die IT benötigt wird. Bisher fand eine Verdoppelung
des Stromverbrauches für die IT alle 5 Jahre statt. (Aebischer, 2011) Wie und woher
die Schweizer IT ihren Strom in Zukunft bezieht ist ungewiss.
2.1.2
20-20-20 in der EU
Die EU hat sich im Dezember 2008 ambitionierte Zielvorgaben im Bereich des
Klimaschutzes und Energie gemacht. Das Ziel mit dem Namen „20-20-20“ beinhaltet
folgende Vorgaben: (European Comission, 2011)



20% weniger Treibhausgasemissionen als 2005
20% Anteil an erneuerbaren Energien
20% mehr Energieeffizienz
Seite 6 von 53
Diese Ziele sollen gemeinsam von den EU-Staaten bis im Jahre 2020 erreicht werden
und werden auch dort in der IT spürbar sein.
2.1.3 The Green Grid Framework
Die globalen Computer-Unternehmen AMD, Dell, IBM, Sun Microsystems und VMware
gründeten im Jahr 2007 das Non-Profit Unternehmen „The Green Grid“. Das Ziel der
Organisation ist, die Energieeffizienz in Rechenzentren zu verbessern. Um dies zu
erreichen, arbeitet „The Green Grid“ mit einzelnen Unternehmen,
Regierungsbehörden und der Industrie zusammen. Es werden Empfehlungen zu Best
Practices und Technologien ausgearbeitet, welche die Energieeffizienz in den
Rechenzentren verbessern soll.
Unter anderem hat „The Green Grid“
verschiedene Standards und Messmethoden für
die Energieeffizienz von Rechenzentren definiert.
Unter anderem ist dies die Power Usage
Abbildung 3 Logo The Green Grid (Grid) Effectivness (PUE) und die Datacenter
Infrastructure Efficiency (DCiE), aus denen der
Rechenzentrumbetreiber schnell eine Energiebilanz erstellen und die Ergebnisse mit
dem Energieverbrauch anderer Rechenzentren vergleichen kann. (Grid)
2.2 Hardware
2.2.1 Client
Gemäss (Wikipedia, 2011) liegt der Energiebedarf eines Standard Thin Clients
zwischen 10 und 20 Watt, während Standard Mehrkern CPUs ohne Peripherie alleine
schon circa 40 bis 120 Watt verbrauchen. In Abbildung 4 wird der Anteil am
Stromverbrauch der Komponenten eines modernen Windows 7 Notebooks
dargestellt.
Seite 7 von 53
Network, 4%
Hard Drive, 6%
Graphics, 9%
Processor, 10%
LCD Panel, 48%
Chipset, 23%
Abbildung 4 Anteil der Komponenten am Stromverbrauch eines Laptops mit Windows 7 (Sinofsky, 2009)
Die Seite www.energystar.ch gibt einen guten Überblick über den Stromverbrauch
aktueller Hardwaremodelle. Energy Star ist ein Label, mit welchem energiesparende
Geräte gekennzeichnet werden. Der erste Markt, wo sich das Label etablierte, war
die USA im Jahr 1992. Es folgte die EU im Jahr 2002 und die Schweiz im Jahr 2009. Die
Liste der Hardwaremodelle beinhaltet keine Serverhardware. (SWICO)
2.2.2 Server
Im Vergleich mit Thin Client Rechnern mit 10 – 12 Watt bewegt sich ein typischer 2U
Server mit einem 450W Netzteil auf einem wesentlich höheren
Energieverbrauchsniveau. In Abbildung 5 ist ersichtlich, dass 35 Prozent (160 Watt)
bereits bei der Energieumwandlung verloren gehen. An zweiter Stelle mit knapp 19
Prozent folgen die (in diesem Fall zwei) Prozessoren mit 86 Watt. An dritter Stelle
folgen die Laufwerke mit 72 Watt.
Seite 8 von 53
140
120
131 W
Watts
100
80
86 W
72 W
60
40
41 W
20
32 W
32 W
DC/DC
losses
Fans
27 W
32 W
0
AC/DC
losses
Drives
PCI cards Processors Memory
Chip set
Losses in power conversion process
Abbildung 5 Verteilung des Energieverbrauchs eines durchschnittlichen Servers (Anderson, 2007)
Ein positives Beispiel ist der von der ETH entwickelte Blade-Server Aquasar. Dank der
Heisswasserkühlung benötigt das System bis zu 40 Prozent weniger Energie im
Vergleich mit einem luftgekühlten System. Mit speziellen Mikrokanalkühlern, welche
auf der Rückseite der Chips angebracht sind, kann die maximal erlaubte
Betriebstemperatur eines Chips von 80°-85°C selbst mit 60°C heissem Wasser noch
garantiert werden. Auf diese Weise wird Abwärme gewonnen, welche direkt an die
Gebäudeheizung weitergegeben wird. Der Hochleistungsrechner Aquasar ist seit
dem 6. Mai 2010 in Betrieb. (ETH Zürich, 2010)
2.2.3 Infrastruktur
Rechencenter haben aufgrund ihrer Leistungsfähigkeit einen sehr hohen Anteil am
weltweiten IT-Energieverbrauch. Wie in Abbildung 6 zu erkennen ist, bewegen sich
die Kosten für Server-Hardware trotz stetiger Leistungs- und Performance-Steigerung
seit 1996 in etwa auf demselben Niveau. In den letzten drei Jahren ist ein leichter
Rückgang ersichtlich, was gemäss der Fachgruppe Green IT (Michel) auf die
Wirtschaftskrise zurückzuführen ist. Bis 2009 bewegten sich die Kosten für Energie und
Kühlung laufend nach oben. Der Rückgang in den letzten drei Jahren ist gemäss
(Michel) nicht auf die Verbesserung des Energieverbrauchs der IT-Infrastrukturen
zurückzuführen, sondern auf die, aufgrund der Wirtschaftskrise, weniger angeschaffte
Server-Hardware. Die Kosten für Kühlung und Energie lagen in den letzten Jahren
stets über der Hälfte der gesamten Kosten für neue Hardware.
Seite 9 von 53
Abbildung 6 Weltweite Kosten für die Energie sowie Kühlung von Servern (Michel)
In Abbildung 7 ist der Energieverbrauch eines typischen Rechenzentrums dargestellt.
Auffallend sind drei grosse Teilbereiche:



Klimageräte (zusammengesetzt aus Kühlaggregaten, Luftbefeuchtern sowie
Klimaanlagen) mit einem Anteil von 45 Prozent,
IT-Ausrüstung (umfasst Server, Speicher, Netzwerk,…) mit einem Anteil von 30
Prozent,
sowie die USV-Anlagen mit einem Anteil von 18 Prozent.
Schaltanlagen/
Generator, 1%
USV, 18%
Beleuchtung, 1%
Kühlaggregate, 33%
Stromverteilung, 5%
Luftbefeuchter, 3%
IT-Ausrüstung, 30%
Klimaanlage, 9%
Grundlage der Grafik ist ein typisches RZ mit 2N Energie und N+1 Kühlausrüstung, mit einer
durchschnittlichen Auslastung von 30%
Abbildung 7 Energieverbrauch eines Rechenzentrums, Daten von (IDG Business Media GmbH, 2009)
Seite 10 von 53
2.3 Software
Nachfolgend werden verschiedene Einflussfaktoren der Software erwähnt, welche in
der Green IT von Bedeutung sind.
2.3.1 Energiesparmodus in Betriebssystemen
Das Betriebssystem ist generell verantwortlich für das Steuern der internen und
externen Geräte. Es soll einen intelligenten Kompromiss zwischen Leistung und
Stromverbrauch bieten. Je nach Nutzung soll das Betriebssystem entscheiden,
welche Geräte eingeschaltet sein sollen. Dem Endbenutzer wird mittels
Energierichtlinien ermöglicht, Einstellungen für den Betrieb von Komponenten (CPU,
Monitor, Festplatte usw.) dem Betriebssystem weiterzugeben. Die aktuellen
Betriebssysteme können diese Managementfunktion über die spezifizierte
Schnittstelle ACPI (Advanced Configuration and Power Interface) wahrnehmen.
ACPI ist ein offenerer Industriestandard für die Energieverwaltung von Computer,
Notebooks und Server.
Der ACPI Standard verfügt unter anderem über verschiedene Stromsparmodi. Unter
anderem wird zwischen den Zuständen G0-G3 unterschieden.
Kürzel
G0
G1
Zustand
Working
Sleeping
G2
G3
Soft Off
Mech Off
Beschreibung
Aktiver Zustand (System läuft)
Schlafzustand (Grosse Teile des Computers sind
abgeschaltet inkl. CPU, diese können jedoch schnell
reaktiviert werden)
Stand-By Zustand
Gerät abgeschaltet mit gezogenem Stromstecker
Tabelle 1 ACPI Stromsparmodi (ACPI, 2010) (Wikipedia, 2011)
Innerhalb des Zustandes G1 werden vier weitere Schlafzustände definiert. In allen
Zuständen werden keine CPU Instruktionen ausgeführt.
Schlafmodus
S1
Beschreibung
Einfachster Schlafmodus.
Wenige Funktionen sind abgeschaltet, die CPU ist angehalten
(Throttle).
S2
Erweiterter Schlafmodus.
Weitere Komponenten sind abgeschaltet, insbesondere der Cache
der CPU.
S3
Standby-Modus (Suspend to RAM, Suspend to memory)
Die meiste Hardware der Hauptplatine ist abgeschaltet, der
Betriebszustand ist auf einem flüchtigen Speicher gesichert.
S4
Ruhezustand (hibernation, suspend to disk)
Der Betriebszustand ist auf einem nicht-flüchtigen Speicher
gesichert.
Tabelle 2 ACPI Schlafmodus (ACPI, 2010) (Wikipedia, 2011)
Seite 11 von 53
2.3.2 Stromverbrauch von Betriebssystemen
Bei der Entwicklung von neuen Betriebssystemen spielt die Energieeffizienz eine
immer grössere Rolle. Dies vor allem, weil die Betriebssysteme vermehrt auf mobilen
Geräten eingesetzt werden und dort die Kapazität der Energie beschränkt ist.
Vergleiche der meistgenutzten Betriebssysteme in Bezug auf den Energieverbrauch
gibt es kaum. Ein Grund dafür sind die unterschiedlichen Einsatzzwecke und die
grosse Vielfalt an verfügbarer Hardware.
Gemäss (Larson, 2009) gibt es wesentliche Punkte, welche einen Einfluss auf den
Energiebedarf eines Computers haben. Einerseits gelten diese Punkte für die
Betriebssysteme selbst, andererseits für die Software, welche auf dem Betriebssystem
läuft.




Anzahl Prozessor WakeUps
Kann die Frequenz der Prozessor WakeUps minimiert werden, benötigt die CPU
weniger Strom. Dies kann mit den verschiedenen Schlafzuständen erreicht
werden.
Energieeffiziente Benutzerinterfaces / Framework
Je nachdem, was für ein Programmierframework eingesetzt wird, ist die
Grundlast des Frameworks höher.
Threading
Obwohl Threading eine höhere Last auf einer Multithreading CPU verursacht,
kann die Aufgabe schneller verarbeitet werden und die CPU somit länger im
Leerlaufmodus sein.
Nutzung von Hardwarebeschleunigung
Vor allem in der Videobearbeitung ist es empfehlenswert, die vorhandene
Hardwarebeschleunigung zu nutzen, anstelle der Verwendung von
Softwarecodecs.
Innerhalb der Software kann sich die Programmiertechnik ebenfalls auf den
Energieverbrauch auswirken.




Die Software sollte den Computer nicht vom Ändern des Energiestatus
hindern.
Die Software sollte auf die Energiequelle reagieren. Das heisst, rechenintensive
Aufgaben (z.B. Windows Updates) sollen nicht im Akkubetrieb ausgeführt
werden.
Der Netzwerkstatus innerhalb einer Software sollte überwacht werden, damit
in einem Offline-Betrieb unnötige Funktionen deaktiviert werden können.
Daten, welche von der Festplatte ins RAM geladen werden, sollten womöglich
minimiert und gruppiert werden. Dies hat eine Minimierung der
Festplattenzugriffe zur Folge.
Diese sehr abstrakten Ansätze zur Reduktion der Leistungsaufnahme von Computern
werden zunehmend an Bedeutung gewinnen, weil die Mobilität, wie bereits erwähnt,
in Zukunft eine grosse Rolle spielen wird. Mit der Mobilität wird die Rechenkapazität
Seite 12 von 53
zunehmend in grosse Rechenzentren ausgelagert, was auch dort eine
energieeffiziente Programmierung voraussetzen sollte.
2.3.3 Virtualisierung
Die Abstraktion von logischen Systemen von deren physischer Implementierung
nennt man Virtualisierung und ist heutzutage stark verbreitet. Die
Virtualisierungstechnologie hat einen unmittelbaren Einfluss auf die Energieeffizienz
von Rechenzentren, da eine effizientere Nutzung der Ressourcen möglich ist.
Gemäss (Koch, 2011) hat die Virtualisierung folgenden Nutzen:
Server-Virtualisierung


Effiziente Ressourcennutzung
o Raumkapazität
o Material / Infrastruktur
o Energie
o Administration / Arbeitsleistung
Flexibilität / Dynamik
Desktop-Virtualisierung



Effiziente Ressourcennutzung
o Thin Clients statt PCs
Kostenreduktion
o Wartung, Support, Energie
Sicherheit
o Daten sind im Serverraum / Rechenzentrum
Als Beispiel wird folgende Aufstellung der Gebäudeversicherung Bern von (Koch,
2011) vorgelegt. Diese zeigt, dass im Falle von Desktop-Virtualisierung mit Thinclients
erheblich Strom gespart werden kann. Der zweite sichtbare Punkt „neue
Serversysteme verwenden“ hat nichts mit der Virtualisierung zu tun.
Abbildung 8 Green IT-Massnahmen der Gebäudeversicherung Bern (Koch, 2011)
Seite 13 von 53
2.3.4 Cloud Computing
„Cloud Computing beschreibt einen internetzentrierten Entwicklungsansatz, bei dem
ein Anbieter komplexe Leistungen aus Soft- und Hardware in Form eines abstrakten
Dienstes bereitstellt. Speicher, Rechenzeit oder komplexere Dienste können über
festgelegte Schnittstellen angefordert werden, wobei es keine Rolle spielt, auf
welcher Hardware diese letztendlich ausgeführt werden.“ (Golem)
Beim Cloud Computing werden drei verschiedene Bereiche betrachtet:



Software as a Service
o Für standardisierte Geschäftsprozesse
o Eingeschränkt konfigurierbar auf Datenebene, jedoch nicht bezüglich
Logik
o Für mobiles, geographisch verteiltes Personal
Platform as a Service
o Eigene Software auf Applikationsservern in der Cloud
o Ideal, wenn Geld / Zeit / Know-How für Virtualisierung / Skalierung fehlt
Infrastructure as a Service
o Bei kurzfristiger Notwendigkeit, die Rechenkapazität zu erhöhen
o Für Applikationen, die viel Speicher oder Bandbreite benötigen
o Für geographisch verteilte Lastverteilung
Weil die Rechencenter, in welchen Cloud Computing betrieben wird, hoch optimiert
sind, ist dort ein effizienter Betrieb möglich. Dieser beinhaltet unter anderem die
Kühlung und dynamische Verteilung der Serverressourcen. Der Einfluss der
Programmierung im Cloud Computing ist bis heute kaum bekannt beziehungsweise
publik. Zurzeit sind die Bestrebungen für den oben erwähnten effizienten Betrieb der
riesigen Rechenzentren hoch, weil dort am meisten Optimierungspotential
vorhanden ist. Doch es anzunehmen, dass in Zukunft in der Cloud die
Programmierung in Bezug auf die Leistungsaufnahme an Bedeutung gewinnen wird.
Ebenfalls ermöglichen die heutigen Cloud Services Endgeräte mit geringem
Energieverbrauch. Das heisst, die Rechenleistung ist nicht wie bei Computern lokal
sondern in der Cloud. Das Endgerät baut eine Verbindung zur Cloud auf und stellt
die Daten lokal dar.
Seite 14 von 53
3 Messungen
3.1 Ziele
Die Messungen haben das Ziel, den Energieverbrauch zweier CMS-Systeme auf
einem Webserver mit unterschiedlichem Betriebssystem zu messen und zu
vergleichen. Dazu werden die zwei verbreiteten Webservertechnologien (Apache
und Microsoft IIS) eingesetzt. Auf beiden Webserver soll ein CMS laufen, welches eine
Webseite zur Verfügung stellt.
Die Messungen werden in fünf verschiedene Szenarien aufgeteilt.
Szenario 1:
Stromverbrauch des Systems ohne zusätzliche Software
Szenario 2:
Stromverbrauch des Systems mit aktiviertem Webserver und Last
Szenario 3:
Stromverbrauch des Systems mit aktiviertem Webserver und
gestartetem CMS (Content Management System) mit Last
Szenario 4:
Stromverbrauch des Systems mit Webserver und
Datenbankoperationen (Lesend und Schreibend)
Szenario 5:
Stromverbrauch des Systems mit Webserver und grossen
Datenbankoperationen (Lesend)
Folgende Rahmenbedingungen gelten für die Versuche:


Nur der Stromverbrauch des Computers wird in die Messung einbezogen
(ohne Bildschirm oder zusätzliche Hardware)
Für die Messungen der verschiedenen Szenarien wird dieselbe Hardware
benutzt (Festplatte darf gewechselt werden, wenn das Modell innerhalb
gleicher Serie dasselbe ist)
Seite 15 von 53
3.2 Versuchsaufbau Hardware
Für den Versuch werden zwei Clients, ein Switch, ein Wattmeter und ein Multimeter
verwendet. Der eine Client wird mit einem Serverbetriebssystem installiert, der andere
generiert die Last auf dem Server durch Senden von Anfragen. Um die elektrische
Leistung zu messen, wird ein Strommessgerät zwischen Stromnetz und Server
geschalten. Dieses erfasst die tatsächlich verbrauchte Leistung des Servers in Wh. Vor
dem Wattmeter wird zusätzlich ein Multimeter von Fluke installiert, welches eine
Messung der aktuellen Spannung via Wechselstromzange erlaubt. Das Multimeter
dient zur Kontrolle der Resultate des Wattmeters und um den Verlauf einer Messung
aufzuzeigen.
Webserver
Netzspannung
230V, 50 Hz
Fluke 289
Mulitmeter
Chitst
CLM210
Wattmeter
Ubuntu
Server 11.10
Microsoft
Windows
Server 2008
R2
100Mbit
Switch
Client
Web Stress Tool
Netzwerkkabel
Netzspannung 230V, 50 HZ
Abbildung 9 Versuchsaufbau physikalisch
3.2.1 Technische Daten der Messgeräte
Christ CLM210
Messbereich
Messfehler
Versorgung
Anschluss
Messrate
Abtastrate
0…4500W / 0.000 – 999 kWh
+/- 0.5% vom Anzeigewert
184-76VAC , 45-65HZ, <4.0VA
Zwischenstecker max. 16A
ca. 1 Sekunde
ca. 4000 Hz
Tabelle 3 Christ CLM210 (Christ Elektronik, 2005)
Fluke 289 Multimeter
Messbereich und
Auflösung
Ungenauigkeit
50,000 mV, 500,00 mV, 5,0000 V,
50,000 V, 500,00 V, 1000,0 V
0,4 % (Echteffektivwert)
Tabelle 4 Fluke 298 Multimeter (Fluke)
Seite 16 von 53
Fluke i200 Wechselstromzange
Kontinuierlicher
Strombereich
Grundungenauigkeit
0,5 A - 200 A
1% + 0,5 A (48-65 Hz) (% vom
Messwert + Grundspez.)
Tabelle 5 Fluke i200 Wechselstromzange (Fluke)
3.2.2 Client Hardwarespezifikationen
Für den Versuch wurde ein Computermodell von HP genommen. Der Computer HP
dc7700 Ultra-slim Desktop ist ein klassischer Desktopcomputer für Firmen. Der
Formfaktor „Ultra-slim“ bedeutet, dass der Computer kleine Masse hat und die
Komponenten nahe bei einander platziert sind. Der Computer besitzt nur einen PCISteckplatz. Nachfolgend sind dessen technischen Details aufgeführt (HP, 2008):
Dimensionen
Grösse (H x B x T)
Gewicht1
7.49 x 31.50 x 33.48 cm
5.48 kg
Komponenten
Prozessor
Chipset
Arbeitsspeicher
Festplatte
Optisches Laufwerk
Grafikkarte
Soundkarte
Netzwerkkarte
Intel Core 2 Duo E6300 Prozessor (1.86-GHz, 2 MB L2 cache,
1066-MHz FSB)
Intel Q965 Express Chipset
2x 1GB DDR2 DRAM
80-GB SATA 3.0-Gb/s Hard Drive (8MB Cache, 7200 rpm)
PATA CD-RW/DVD-ROM Combo Slim Drive
Integrated Intel Graphics Media Accelerator 3000
Integrated High Definition audio with Realtek 4-channel
ALC262 codec
Integrated Intel 82566DM Gigabit Network Connection
Ethernet
Netzteil
Stromversorgung
200 Watt
3.3 Versuchsaufbau Software
Für die verschiedenen Szenarien werden unterschiedliche Softwarekonfigurationen
benötigt, welche pro Szenario als Festplattenabbilder gespeichert werden. Dadurch
ist die Reproduzierbarkeit der einzelnen Szenarien gewährleistet. Nachfolgend wird
auf die entsprechenden Technologien und Tools eingegangen, welche für den Test
benötigt werden.
1
Konfiguriert mit Festplatte, CD-Rom Laufwerk und ohne Diskettenlaufwerk, PCI Karte
Seite 17 von 53
3.3.1 Webserver
Im Versuch werden Apache 2 und Microsoft IIS 7.5 als Webserver benutzt. Diese
gehören, wie in Abbildung 10 zu sehen ist, zu den in der Schweiz am weitest
verbreiteten Webservern, Stand 1.4.2011 – 30.6.2011 (NetObservatory, 2011). Als
Betriebssystem für den Apache Server wird Ubuntu Server 11.10, für den Microsoft IIS
7.5 Windows Server 2008 R2 verwendet.
Abbildung 10 Top 10 Webserver (NetObservatory, 2011)
3.3.2 CMS
In Abbildung 11 ist ersichtlich, welche CMS in der Schweiz am weitesten verbreitet
sind. Für das Hosting auf Ubuntu Server wird das CMS „Joomla“ ausgewählt. Unter
den ASP.NET basierten CMS wird „DotNetNuke“ als Windows Hosting für den Test
ausgewählt, da dieses weltweit unter den .NET CMS die grösste Anwendung findet
(water & stone, 2011).
Abbildung 11 Top 10 CMS (NetObservatory, 2011)
Seite 18 von 53
3.3.3 Software Windows Server 2008 R2
Für den Versuchsaufbau wurde der Windows Server mit folgenden Komponenten
standardmässig installiert:






Betriebssystem: Microsoft Windows Server 2008 R2 Standard Edition
Webserver: IIS 7.5
Datenbank: Microsoft SQL Server 2008 R2
CMS Version: DotNetNuke 6.0
ASP.NET 3.5.1
Windows Updates: Deaktiviert
DotNetNuke wurde via WebPlatform-Installer von Microsoft installiert.
3.3.4 Software Ubuntu Server
Die Installation des Linux Servers beinhaltet folgende Komponenten:





Betriebssystem: Ubuntu Server 11.10
Webserver: Apache 2.2.14
Datenbank: MySQL 5.1.58
CMS Version: Joomla 1.7.2
PHP Version: 5.3.6-13ubuntu3.2
Die verschiedenen Komponenten wurden ebenfalls nach Standard installiert, es
wurden keine spezifischen Anpassungen vorgenommen.
3.3.5 Webserver Lastgenerierung
Ein Client ist zuständig, dass Last auf dem Webserver generiert wird. Für die
Lasterzeugung wird das Tool „Webserver Stress Tool“ (Paessler AG) verwendet.
Das Tool simuliert bis zu 10‘000 User, welche, voneinander unabhängig, definierte
Klicks auf beliebigen Websites ausführen. Via Script Files können auch komplexere
Aktionen wie ein Login durchgeführt werden. Das Verhalten der einzelnen User
während des Versuchs wird protokolliert.
Abbildung 12 Eingabemaske der Parametrisierung des Webserver Stress Tools
Seite 19 von 53
Es werden unterschiedliche Testmethoden unterstützt. Mit Parametern kann man
eigene Szenarien definieren, die wichtigsten sind nachfolgend aufgeführt.
Webserver Stress Tool – Test Spezifizierung
 Clicks
Der Test läuft, bis die definierte Anzahl Klicks pro
User erreicht wird. Die Last ist konstant.
Test-Typ
 Time
Der Test läuft, bis die definierte Ausführungszeit
abgelaufen ist. Auch hier ist die Last konstant.
 Ramp
Der Test läuft, bis die definierte Ausführungszeit
abgelaufen ist. Die Last steigt kontinuierlich an.
Zeitdauer des Testes
Anzahl Benutzer
Klick Verzögerung
Die Dauer des Testes kann in Minuten definiert
werden. Dies ist nur für die Test-Typen „Time“ und
„Ramp“ verfügbar.
Mithilfe dieses Parameters kann die maximale
Anzahl der virtuellen User angegeben werden, die
an der Lasterzeugung teilnehmen.
Mithilfe dieses Parameters kann definiert werden,
in welchen Zeitabständen jeder User die URL
beziehungsweise das URL-Script aufruft.
Tabelle 6 Webserver Stress Tool - Test Spezifizierung
Bei der Lasterzeugung dürfen die Anfragen pro Zeiteinheit nur so hoch sein, dass
beide Webserver (IIS/Apache) stets in der Lage sind, alle Anfragen
entgegenzunehmen und zu beantworten, da sonst die Messresultate verfälscht
würden.
3.4 Erwartung
Die erste Messung soll generell den Stromverbrauch von Ubuntu und Windows auf
gleichbleibender Hardware aufzeigen. Da beide Betriebssysteme die aktuellen
Standards des Energiemanagements (APCI) unterstützen und in selber Weise
konfiguriert sind (beispielsweise kein Standby nach 30 Minuten), ist ein kleiner
Unterschied beim Energieverbrauch zu erwarten. Da beides Server-Betriebssysteme
sind, ist anzunehmen, dass ähnlich viele Prozesse gestartet sind.
Für das zweite Szenario wird zusätzlich Last auf dem Webserver generiert. Im Versuch
ist der Aufruf einer einfachen Webseite vorgesehen. Es ist anzunehmen, dass diese
Aufgabe vom Webserver ohne grosse Probleme bewältigt werden kann. Somit wird
kaum Rechenleistung gebraucht und es ist mit wenigen Diskzugriffen zu rechnen.
Daraus wird ein ähnliches Resultat wie bei Szenario 1 erwartet, welches kaum
Unterschiede zwischen den Betriebssystemen aufweist.
In Szenario 3 werden die beiden CMS-Systeme auf dem jeweiligen Webserver
installiert. Ein CMS besteht aus vielen Zeilen Code, die Effizienz des Codes kann somit
stark variieren. Dies wird zur Folge haben, dass die Ressourcen des Computers
Seite 20 von 53
unterschiedlich ausgelastet sein werden. Dementsprechend wird der
Stromverbrauch sein. Es wird angenommen, dass das System, welches durch die
Anfragen mehr belastet wird, mehr Strom benötigt. Aufgrund des analogen
Seitenaufbaus der beiden Websites ist jedoch ein ähnlich hoher Rechenaufwand auf
den Servern zu erwarten, was einen entsprechend kleinen Unterschied im
Energieverbrauch zur Folge haben wird.
Szenario 4 beinhaltet Datenbank- und Webserver-Rechenoperationen. Es werden
Daten in eine Datenbank geschrieben und anschliessend ausgelesen. Da mit einer
leeren Datenbank gestartet wird, wird die Last im Verlaufe des Tests zunehmen. Je
mehr Datenbankeinträge gelesen werden, desto höher ist die Auslastung und somit
der Stromverbrauch des Rechners. Es wird angenommen, dass der Stromverbrauch
unter demjenigen von Szenario 3 liegen wird, da weniger Logik pro Webseitenaufruf
durchgelaufen werden muss.
Das letzte Szenario soll die Grenzen des Systems aufzeigen. Mit einer grösseren
Datenbank wird sich der Aufwand pro Abfrage enorm vergrössern. Da bei jedem
Seitenaufruf sämtliche Datensätze abgerufen werden, wird die Last auf dem Server
als hoch eingeschätzt. Dementsprechend wird eine hohe Auslastung des Webservers
und somit ein hoher Stromverbrauch erwartet.
3.5 Messmethode
Die oben definierten Szenarien werden je eine Stunde gemessen. Vor der Messung
wird der Server gestartet und während 5 Minuten ohne Interaktion laufen gelassen.
Dies soll eventuelle Störeinflüsse von Startroutinen des Betriebssystems eliminieren.
Während der einstündigen Messung ist der aktuelle Strombedarf in Watt und die
kumulierte Leistung in Wattstunden ersichtlich. Das Multimeter von Fluke zeichnet den
Verlauf der Spannung während der Messung auf.
Dabei wird das Wattmeter zwischen Server und dessen Stromquelle geschaltet. Die
beiden Systeme (Windows/Ubuntu) werden mit derselben Hardware gemessen.
Einzig die Server-Festplatte wird jeweils gewechselt, um die Szenarien zeitnah zu
präparieren und durchzuführen.
Mithilfe des Tools „Webserver Stress Tool“ werden 40 virtuelle Benutzer simuliert,
welche im Rhythmus von 10 Sekunden auf die jeweilige Webseite zugreifen (TestModus „Time“).
3.6 Versuchsablauf
Nachfolgend wird detailliert aufgezeigt, wie die Versuche pro Szenario vorbereitet
und durchgeführt werden.
3.6.1 Szenario 1
Bei Szenario 1 ist noch kein lasterzeugender Client notwendig. Das Strommessgerät
soll den Energieverbrauch der Server-Grundsysteme im Leerlauf messen.
Der Ubuntu Server wird nach der Anleitung der deutschen Ubuntu Community
(ubuntuusers.de, 2011) gemäss Standard installiert. Es werden keine zusätzlichen
Seite 21 von 53
Pakete zum Grundsystem hinzugefügt. Der Windows Server wird als Windows Server
2008 R2 Standard installiert.
Die Installation der beiden Server-Systeme beschränkt sich auf die vom
Betriebssystem allgemein benötigten Komponenten. Auf diese Weise werden
Fremdeinflüsse auch auf Software-Seite aufs Minimum reduziert. Der
Energieverbrauch der beiden Systeme wird nun gemäss der in Kapitel 3.4 definierten
Messmethode gemessen.
3.6.2 Szenario 2
In Szenario 2 soll im Gegensatz zu Szenario 1 die Webserver-Komponente
(Apache/IIS) mitinstalliert und aktiviert werden.
Der Ubuntu Server wird für Szenario 2 als LAMP-Server (Linux Apache MySQL PHP
Server) eingerichtet. Nach der Installation muss sichergestellt werden, dass das
Apache-Modul auch aktiviert ist. Beim Windows Server wird nun die Webserverrolle
(IIS) installiert und der Dienst anschliessend aktiviert.
Nun wird die Lasterzeugung miteinbezogen. Die Last wird jedoch noch nicht über
das CMS erzeugt, sondern erst einmal mithilfe einer ASP-Seite für den Windows Server
sowie einer analogen PHP-Seite für den Ubuntu Server. Im Wesentlichen bestehen die
Webseiten aus einem grafischen Header, ein paar Zeilen Text sowie einem aktuellen
Zeitstempel (Siehe Abbildung 13).
Abbildung 13 Szenario 2: Einfache ASP/PHP Webseite
3.6.3 Szenario 3
In diesem Szenario wird das CMS mit in die Messung miteinbezogen. Deshalb muss
auf beiden Server-Systemen das jeweilige CMS installiert werden. Die Lasterzeugung,
welche die CMS zu Datenbankanfragen provozieren soll, übernimmt der ClientComputer mithilfe des Webserver Stress Tools.
Seite 22 von 53
Um eine „faire“ Ausgangslage zu erreichen, wurden auf beiden CMS Webseiten mit
analogem Seitenaufbau (Header, Textinhalt, Datum- und Zeitstempel) erzeugt. Um
das CMS zusätzliche zu belasten, wurde auf beiden CMS das vorinstallierte Plugin
„User Online“ (DotNetNuke) beziehungsweise „Who’s online“ (Joomla) aktiviert.
Dieses Plugin zeigt an, wie viele Benutzer sich zurzeit auf der Seite befinden. Mit dem
Plugin wird bei jedem Seitenaufruf eine Aktualisierung des Inhalts erzwungen.
Abbildung 14 Szenario 3: Startseite von Joomla
Abbildung 15 Szenario 3: Startseite von
DotNetNuke
3.6.4 Szenario 4
Für das Szenario 4 wurde eine ASP.NET sowie eine PHP Seite erstellt, mit welchen
anhand SQL- Operationen (Read/Write) und anschliessendem Ausgeben der
abgefragten Daten auf der Website Last erzeugt wird.
Konkret werden zuerst anhand zwei URL-Parameter beim Aufrufen der Webseite
dynamische Datenbank-Einträge generiert und anschliessend die generierten
Einträge aufgelistet. Dynamisch deswegen, weil das Webserver Stress Tool in der
Lage ist, anhand einer CSV-Datei die URL-Parameter zufällig zu generieren.
Der Setup des Webserver Stress Tool in diesem Szenario sieht wie folgt aus:



40 Benutzer rufen im jeweiligen Abstand von 10 Sekunden eine URL-Folge auf.
Die URL-Folge besteht aus einer URL für die Schreiboperation sowie einer URL
für die Leseoperation
Die Schreiboperation fügt einen neuen Datensatz in die Datenbank ein, die
Leseoperation liest jeweils die 3000 letzten Einträge aus und gibt sie aus.
Seite 23 von 53
Abbildung 16 Szenario 5: Schreiben von einem Datensatz
Abbildung 17 Szenario 5: Lesen von Datensätzen
3.6.5 Szenario 5
Das Szenario 5 wurde nach Abschluss der vorherigen Szenarien in Rückfrage mit dem
Wirtschaftspartner definiert und realisiert. Es soll aufzeigen, wie sich der
Stromverbrauch bei grossen Datenbankoperationen verhält. Somit wurden vor der
Messung 100‘000 Testdatensätze in der Datenbank erfasst. Das Szenario hat
folgenden Ablauf:



Alle Datensätze via SQL abrufen
Alle Datensätze im Code durchlaufen (Schleife)
Passende Datensätze auf der Webseite anzeigen (Anhand Vergleich von
aktuellem Datensatz mit URL Parameter)
Die Filterung der 100‘000 Datensätze erfolgt also explizit im Code.
Abbildung 18 Szenario 5: Lesen von Datensätzen
Ein weiteres Ziel dieses Szenario ist, die allgemeine Performance des Apache &
MySQL respektive IIS& MSSQL-Servers zu testen, um eine Aussage über deren Einfluss
auf die Performance des jeweiligen CMS von Szenario 3 zu erhalten.
Seite 24 von 53
4 Resultate der Messungen
Die Tabelle 7 zeigt die absoluten Messresultate der Szenarien 1-5 in der Übersicht. Die
folgenden Unterkapitel gehen genauer auf die Resultate der jeweiligen Szenarien
ein, beinhalten aber keine Auswertung.
Szenario 1
Szenario 2
Ubuntu
66.9 Wh
67.7 Wh
Windows
67.3 Wh
66.6 Wh
Szenario 3
78.8 Wh
90.9 Wh
Szenario 4
67.3 Wh
68.0 Wh
Szenario 5
88.9 Wh
89.3 Wh
Bemerkung













Betriebssystem im Leerlauf
IIS/Apache aktiviert
Lastgenerierung durch Aufruf statischer HTML-Seite
CMS installiert
Lastgenerierung durch Aufruf der CMS-Startseite
Lastgenerierung durch Aufruf von PHP/ASPX Seite
Schreiboperation fügt neue Einträge in DB
Leseoperation gibt die letzten 3‘000 Einträge aus
Filterung auf DB-Ebene
Datenmenge: Steigend von 0 bis 7120 Records
Lastgenerierung durch Aufruf von PHP/ASPX-Seite
Filterung im Code
Datenmenge: 100‘000 Records
Tabelle 7 Messresultate Szenario 1-5
4.1 Szenario 1
Ohne Belastung benötigt Windows im Leerlauf leicht mehr Strom als Ubuntu, der
Unterschied beträgt 0.4 Wh. Wenn man jedoch den Messfehler des Messgeräts (±
0.5% vom Anzeigewert, hier absolut ±~0.33 Wh) miteinbezieht, kann diese Differenz
vernachlässigt werden.
4.2 Szenario 2
Die Belastung durch das Aufrufen der statischen HTML-Seite ist sehr gering. Trotz
Beantwortung von Anfragen werden beide Server kaum belastet. Die CPUAuslastung bewegte sich auf beiden Systemen zwischen null und zwei Prozent. In
Szenario 2 konsumierte der Windows Server trotz Webseitenanfragen gar weniger
Strom als in Szenario 1. Dies ist einerseits auf den Messfehler des Messgeräts
zurückzuführen, andererseits auf unregelmässig laufende Windows Prozesse. Es wurde
beobachtet, dass in Szenario 1 gelegentlich der .NET Runtime Optimization Service
ausgeführt wurde, welcher den Windows Server teilweise mit ein paar Prozent CPUAuslastung zusätzlich auslastete. Wenn man Ubuntu mit Windows vergleicht, fällt auf,
dass Ubuntu mit 67.7 Wh absolut 1.1 Wh mehr Strom konsumierte. Auch wenn man
den Messfehler berücksichtigt, liegt der Stromkonsum von Ubuntu in diesem Szenario
immer noch leicht höher.
Seite 25 von 53
Ubuntu
67.7
~67.36
~68.04
Messwert
Unterer Schwellwert (-0.5%)
Oberer Schwellwert (+0.5%)
Windows
66.6
~66.27
~66.93
Tabelle 8 Berücksichtigung des Messfehlers in Szenario 2
Auch im Extremfall (gelbe markierte Werte der Tabelle 8) liegt der Stromkonsum des
Ubuntu Servers 0.43 Wh höher als derjenige des Windows Servers.
4.3 Szenario 3
Das Resultat des dritten Szenarios ist überraschend. Der Windows Server mit dem CMS
„DotNetNuke“ konsumierte deutlich mehr Strom als der Ubuntu Server mit dem CMS
„Joomla“. In Zahlen bedeutet dies 12.1 Wh Mehrverbrauch. Wird der Messwert des
Windows Servers als 100% angenommen, beträgt der Unterschied zu Ubuntu ~13.3%.
7000
Antwortzeit in [ms]
6000
5000
4000
3000
2000
1000
0
0
5
10
15
20
25
30
35
40
45
50
55
Vergangene Zeit in Minuten
Antwortzeit DotNetNuke [ms]
Antwortzeit Joomla [ms]
Abbildung 19 Szenario 3: Antwortzeiten der beiden CMS
Abbildung 19 zeigt den enormen Performanceunterschied der beiden CMS-Systeme.
Die durchschnittliche Antwortzeit von Joomla liegt bei 214 ms (untere Linie), bei
DotNetNuke auf sehr hohen 1426 ms (obere Linie). Kurzzeitig lag die Antwortzeit der
DotNetNuke Testseite gar bei über 6 Sekunden. Aus den sehr hohen Antwortzeiten
von DotNetNuke kann man ableiten, dass auf dem Windows Server für einen
Seitenaufruf deutlich mehr „gerechnet“ werden muss. Dies resultiert wie bereits oben
beschrieben im höheren Stromverbrauch.
Die sehr hohen Antwortzeiten des Windows Servers führten dazu, dass mit 12‘499
beantworteten Anfragen knapp 1400 Anfragen weniger beantwortet wurden als
gegenüber dem Ubuntu Server (13‘895 beantwortete Anfragen).
Seite 26 von 53
4.4 Szenario 4
Mit 68 Wh konsumierte der Windows Server 0.7 Wh mehr Strom als der Ubuntu Server.
Dies ist unter Berücksichtigung des Messfehlers noch etwas über 0.02 Wh Unterschied.
Die Abbildung 20 stellt die Antwortzeiten der Leseoperation vom Windows- sowie
vom Ubuntu Server dar. Die im Verlaufe des Szenarios steigenden Antwortzeiten
wiederspiegeln die aufgrund der Schreiboperation steigende Datenmenge. Mit jeder
Leseoperation werden die letzten 3000 Einträge ausgelesen und dargestellt. Da die
Datenmenge anfangs noch unter 3000 Einträgen liegt, sind die Antwortzeiten der
beiden Server anfangs noch gering. Ebenfalls ist zu erkennen, dass die Antwortzeiten
sich bei Windows nach ungefähr 25 Minuten, bei Ubuntu nach ca. 30 Minuten
stabilisieren. Auffällig ist, dass der Ubuntu Server auch nach Überschreitung der 3000
Einträge hohe instabile Impulse der Antwortzeit aufweist. Der Windows Server hatte
mit einer durchschnittlichen Antwortzeit von 58 ms rund 6 ms länger für die
Beantwortung der Anfragen als der Ubuntu Server. Die Schreiboperation war mit
durchschnittlichen Antwortzeiten von 11ms (Windows Server) und 13 ms (Ubuntu
Server) nicht ausschlaggebend.
180
160
Antwortzeit in in [ms]
140
120
100
80
60
40
20
0
0
5
10
15
20
25
30
35
40
45
50
55
Vergangene Zeit in Minuten
Windows
Ubuntu
Abbildung 20 Antwortzeiten der Leseoperation (Windows/Ubuntu)
Seite 27 von 53
4.5 Szenario 5
Szenario 5 resultierte sowohl für den Windows- als auch den Ubuntu Server in einem
hohen Stromverbrauch. Mit 88.9 Wh (Ubuntu) und 89.3 Wh (Windows) liegen die
beiden Werte innerhalb des Toleranzbereichs durch den Messfehler. Damit lässt sich
die Differenz von 0.4 Wh vernachlässigen.
Die durchschnittliche Antwortzeit war bei Ubuntu mit 1412 ms deutlich tiefer als bei
Windows mit 2195 ms. Auch in diesem Szenario schlägt sich die hohe Antwortzeit vom
Windows Server auch in der Anzahl beantworteten Anfragen nieder. 11‘710
beantwortete Anfragen sind rund 700 weniger als beim Ubuntu Server. Trotzdem war
die CPU-Auslastung beider Systeme durchgehend bei 90%-95%. Daraus resultiert
auch der minimale Unterschied im Stromverbrauch von 0.4 Wh. Trotz ähnlich hohem
Stromverbrauch war die Performance des Ubuntu Server (PHP / MySQL) besser als
diejenige des Windows Servers (ASPX / MSSQL).
Seite 28 von 53
5 Auswertung der Messungen
Nachfolgend werden die einzelnen Szenarien der Reihe nach ausgewertet und mit
den definierten Erwartungen verglichen.
5.1 Vergleich Erwartungshaltung gegenüber Messresultate
Wie erwartet schlägt sich die Implementation des APCI-Standards beider
Betriebssysteme in einem Energieverbrauch auf ähnlich hohem Niveau nieder. Die
Erwartungshaltung von Szenario 1 wurde somit mit der Messung bestätigt.
In Szenario 2 war die Erwartung ein ähnlich hoher Energieverbrauch wie in Szenario 1.
Der Stromverbrauch des Ubuntu Servers lag nach Abzug des Messfehlers 0.43 Watt
höher als noch in Szenario 1. Der Windows Server lag mit 66.6 Watt gar 0.7 Watt unter
dem Wert von Szenario 1. Dies ist entgegen der Erwartungshaltung. Dass die
Belastung der kleinen statischen Seite gering ist, wurde erwartet. Die Faktoren wie
unregelmässig laufende Prozesse auf dem Windows Server oder der bei geringen
Wert-Unterschieden stark bemerkbare Messfehler wurden in der Erwartungshaltung
nicht berücksichtigt.
Die Erwartungshaltung von Szenario 3 wurde nur teilweise bestätigt. Wie Abbildung
19 zeigt, waren die Antwortzeiten beim Windows Server durchschnittlich über
sechsmal höher als diejenigen des Ubuntu Servers. Wie erwartet resultierte der
höhere Aufwand für die Darstellung der Webseite in einem höheren Stromverbrauch,
welcher 12.1 Wh beträgt. Dieser doch beträchtliche Unterschied zwischen
DotNetNuke und Joomla wurde nicht erwartet.
Auch die Erwartungshaltung von Szenario 4 wurde nur teilweise bestätigt. Wie
Abbildung 20 zeigt, steigen die Antwortzeit und damit der Rechenbedarf im Verlaufe
des Tests. Der Zusammenhang zwischen dem Rechenbedarf und der Antwortzeit
wurde wie erwartet bestätigt. Nicht erwartet wurde jedoch der so geringe
Unterschied des Stromverbrauchs im Vergleich zu Szenario 1. Zwar liegt der
Stromverbrauch wie erwartet unter demjenigen des dritten Szenarios, dass der
Unterschied jedoch nicht einmal ein Watt beträgt, deckt sich nicht mit der
Erwartungshaltung.
Die hohe Anzahl Datensätze von Szenario 5 und das vollständige Auslesen von Daten
in jedem Seitenaufruf hatte wie erwartet einen hohen Stromverbrauch beider
Systeme zur Folge.
5.2 Gegenüberstellung der Szenarien
Nachfolgend werden die Szenarien miteinander verglichen um daraus Schlüsse zu
ziehen. Dazu nochmals der Hinweis, dass in den Szenarien 2-5, wo Lastgenerierung
miteinbezogen wurde, jeweils dieselbe Last von 40 Benutzern mit jeweils zehn
Sekunden Klickverzögerung pro Benutzer verwendet wurde.
Die reine Beantwortung von Anfragen benötigt kaum CPU und resultiert
entsprechend in geringem Mehrstromverbrauch in Bezug zum Grundsystem im
Leerlauf. Dies bestätigen die Werte von Szenario 2 im Vergleich zu Szenario 1. Trotz
der erheblichen Belastung durch Anfragen, welche in Szenario 3 beispielsweise zu
Seite 29 von 53
einem Stromverbrauch von 135% auf Windows-Seite und 118% auf Ubuntu-Seite im
Vergleich zum Grundsystem führte, war der Stromverbrauch in Szenario 2 nicht
(Windows Server) beziehungsweise nur minim (Ubuntu Server) gestiegen. Dies beweist
der minimale Anteil am Stromverbrauch der reinen Entgegennahme und
Beantwortung von Anfragen. Der eigentliche Stromverbrauch liegt also im
Verarbeiten der Anfrage, sprich des Durchlaufens der PHP- respektive ASPX-Codes.
Dasselbe gilt für Szenario 4. Trotz durchschnittlichen Antwortzeiten der Lese- und
Schreiboperation von total immerhin 65 ms (Ubuntu) und 69 ms (Windows) war der
Mehrstromverbrauch nach Berücksichtigung des Messfehlers bei Ubuntu null und bei
Windows 0.02 Wh.
Die Abbildung 21 und Tabelle 9 zeigen die Antwortzeiten und der Stromverbrauch
der Szenarien 2 bis 5 im Überblick. Ein Zusammenhang der Antwortzeiten und des
Stromverbrauchs ist ersichtlich. Eine hohe durchschnittliche Antwortzeit zieht einen
hohen Stromverbrauch mit sich. Bei einer tiefer durchschnittlichen Antwortzeit ist
auch der Stromverbrauch entsprechend tief. Die Linearität zwischen dem
Stromverbrauch und der Antwortzeit kann hier trotzdem nicht eindeutig bestätigt
beziehungsweise widerlegt werden. In Szenario 5 beispielsweise war der
Stromverbrauch beim Windows Server tiefer als noch in Szenario 3, obwohl die
durchschnittliche Antwortzeit höher war. In Kapitel 6.3.6 wird diese Linearität anhand
der Erweiterungsmessung 6 untersucht.
2500
100
90
80
Antwortzeit in [ms]
70
1500
60
50
1000
40
30
500
Stromverbrauch in [Wh]
2000
20
10
0
0
S2
S3
S4
S5
Durchschn. Antwortzeit Ubuntu
Durchschn. Antwortzeit Windows
Stromverbrauch Ubuntu
Stromverbrauch Windows
Abbildung 21 Stromverbrauch und Antwortzeiten der Szenarien 2 bis 5 im Überblick
Seite 30 von 53
S2
S3
S4
S5
Stromverbrauch
Ubuntu [Wh]
67.7
78.8
67.3
88.9
Stromverbrauch
Windows [Wh]
66.6
90.9
68
89.3
Durchschn. Antwortzeit
Ubuntu [ms]
14
214
65
1412
Durchschn. Antwortzeit
Windows [ms]
15
1426
69
2195
Tabelle 9 Wertetabelle Vergleich Szenario 2 -5
In Szenario 3 waren die durchschnittlichen Antwortzeiten von Ubuntu um 84% tiefer
als diejenigen von Windows. Ob dies nun vom CMS oder vom Webserver inklusive
Datenbank verursacht wird, ist in diesem Szenario nicht ersichtlich. Mit der
Gegenüberstellung der Antwortzeiten von Szenario 3 zu Szenario 5 lässt sich hier
jedoch eine Aussage machen. Unter Szenario 5 war die Antwortzeit des Ubuntu
Servers um 35% geringer. Szenario 5 beinhaltet analoge Webseitenaufrufe mit
Datenbankzugriffen, jedoch ohne CMS. Die 35% tieferen Antwortzeiten sind somit ein
Resultat des Performanceplus vom Ubuntu Server im Vergleich zum Windows Server.
Die Differenz zu den 84% tieferen Werten von Szenario 3 beruht somit auf
Performanceunterschieden der CMS und beträgt 49%. Zusammengefasst bedeutet
dies, dass nicht nur Joomla in diesem Szenario performanter ist als DotNetNuke,
sondern auch der Ubuntu Server die bessere Performance aufweist als der Windows
Server.
Zur Verifikation der Antwortzeiten, welche in Szenario 5 gemessen wurden, wird eine
erweiterte Messung mit weniger Last im Kapitel 6.3.7 durchgeführt. Diese Messung soll
dazu dienen, die 35% niedrigeren Antwortzeiten vom Ubuntu Server gegenüber dem
Windows Server zu bestätigen.
5.3 Resultate kritisch analysieren
Aufgrund des Messfehlers und nicht vorhersagbaren Aspekten wie unregelmässig
laufenden Prozessen müssen minimale Unterschiede im Stromverbrauch wie die
0.4 Wh Unterschied zwischen Windows und Ubuntu in Szenario 1 relativiert werden.
Daraus Vorteile von einem der beiden Systeme zu erkennen wäre falsch. Hingegen
kann man daraus erkennen, dass der Energiekonsum beider Systeme im Leerlauf auf
demselben Niveau liegt.
Eine weitere Erkenntnis ist der Einfluss des Programmcodes auf den Stromverbrauch.
In Szenario 3 war der Unterschied im Stromverbrauch der beiden visuell analogen
CMS-Seiten überraschend hoch. Dass diese Differenz trotz denselben Grafiken,
derselben Textmenge und dem analogen Seitenaufbau zustande kommt, ist auf den
Programmcode von DotNetNuke zurückzuführen. Szenario 4 beweist, dass die reine
Beantwortung von nicht rechenintensiven Anfragen weder für den Windows- noch
für den Ubuntu-Webserver zu mehr als einem Watt Mehrstromverbrauch führt.
Die bisherigen Messungen behandelten den jeweiligen Server als Blackbox. Der
Stromverbrauch wird vom gesamten System gemessen. Welchen Anteil
Komponenten wie CPU, Disk oder Netzwerkkarte am Stromverbrauch haben, ist aus
Seite 31 von 53
den bisherigen Messungen nicht ersichtlich. Auf dieses Thema wird in den erweiterten
Messungen (siehe Kapitel 6) näher eingegangen.
Der Fokus wurde bisher auf absolute Strommessungen gelegt. In den erweiterten
Messungen wird der dynamische Verlauf des Stromverbrauchs mitberücksichtigt,
beispielsweise bei stetig steigender Last innerhalb eines bestimmten Zeitfensters.
Seite 32 von 53
6 Erweiterte Messungen
Auf den Erkenntnissen der Szenarien eins bis fünf werden in diesem Kapitel erweiterte
Messungen experimenteller Art betrachtet. Die erweiterten Messungen dienen dazu,
bisherige Messresultate kritisch zu hinterfragen und mit neuen Messungen zu
verifizieren. Da die Messungen experimenteller Art sind, werden diese nicht wie bis
anhin auf beiden Plattformen durchgeführt und die Messdauer wird individuell
festgelegt.
Es werden folgende erweiterte Messungen (EM) definiert:
EM 1:
Stromverbrauch des Systems im BIOS (ohne Betriebssystem)
EM 2:
Stromverbrauch des Systems mit voller CPU Last
EM 3:
Stromverbrauch des Systems mit voller Disk Last
EM 4:
Stromverbrauch des Systems bei Datentransfer über das Netzwerk
EM 5:
Stromverbrauch Szenario 5 (Ubuntu) mit Datenfilter durch SQL
Statement anstelle im Code
EM 6:
Stromverbrauch Szenario 5 (Windows) bei steigender Last
EM 7:
Stromverbrauch Szenario 5 (Windows/Ubuntu) mit geringerer Last
6.1 Erwartungshaltung
Für die erste erweiterte Messung ist zu erwarten, dass der Computer ohne
Betriebssystem gleich viel Strom benötigt wie mit Betriebssystem ohne Last. Das
Betriebssystem verursacht nicht mehr Strom, da nur wenige Hintergrundprozesse
ausgeführt werden.
In Szenario 3 wurde eine Leistungsaufnahme von 90.9 Watt und eine hohe CPU Last
auf dem System beobachtet. Da das Szenario hauptsächlich CPU-, Memory- und
Netzwerklast verursachte, ist anzunehmen, dass die CPU der Hauptverbraucher des
Stroms ist. Es ist zu erwarten, dass die CPU den Leistungsunterschied zwischen
Szenario 1 und 3 ausmacht und der Stromverbrauch der erweiterten Messung 2
aufgrund voller CPU-Auslastung noch etwas höher als in Szenario 3 liegt.
In EM 3 soll aufgezeigt werden, wie viel Leistung die Festplatte bei voller Auslastung
aufnimmt. Da in den bisherigen Szenarien kaum Festplattenauslastung beobachtet
werden konnte, ist es unmöglich, eine Voraussage in Watt zu machen. Es wird
angenommen, dass der Leistungsunterschied zwischen laufender und ausgelasteter
Festplatte nicht so stak sein wird wie bei der CPU, da die Festplatte im Leerlauf in der
eingesetzten Hardware gleich schnell läuft wie unter Last.
In EM 4 wird erwartet, dass der Einfluss der Netzwerkauslastung auf den Computer
sehr gering ist, da für den Netzwerkverkehr die Daten vom Adapter direkt ins Memory
transferiert und von der CPU verarbeitet werden. Bei voller Auslastung des Netzwerks
wird ein zusätzlicher Stromverbrauch aufgrund von höherer CPU Auslastung erwartet.
Seite 33 von 53
In Szenario 5 wurde die Leistungsaufnahme einer Webseite gemessen, welche grosse
Datenmengen im Code filtert. Es wird erwartet, dass sich die Leistungsaufnahme des
Servers minimiert, wenn die Filterung nicht im Code über eine Schleife, sondern
optimiert via SQL-Abfrage stattfindet.
Mit EM6 soll aufgezeigt werden, ob einer steigenden Last auf dem Webserver eine
steigende Leistungsaufnahme gegenübersteht. Es wird erwartet, dass sich die
Leistungsaufnahme linear verhält, nach einer gewissen Zeit jedoch eine
Leistungsobergrenze erreicht wird und die Last sowie die Leistungsaufnahme
stagniert.
EM 7 dient zur Verifikation von Szenario 5. Es wird erwartet, dass die Antwortzeiten des
Ubuntu Servers auch bei geringerer Last rund 35% tiefer liegen werden als diejenigen
des Windows Servers.
6.2 Messaufbau
Die erweiterten Messungen werden auf derselben Infrastruktur durchgeführt wie die
bisherigen Szenarien. Für die Messungen war teilweise zusätzliche Software
notwendig. Die eingesetzten Tools werden in den nachfolgenden Kapiteln kurz
beschrieben.
6.2.1 Cpukiller3
Um die CPU eines Computers vollständig auszulasten wurde das Tool „Cpukiller3“
verwendet. Mit diesem Tool können beide Kerne der CPU vollständig ausgelastet
werden. Somit ist es möglich, den Stromverbrauch der CPU zu eruieren.
6.2.2 Crystal Disk Mark 3.0.1b
Mit Crystal Disk Mark kann die Festplatte auf Lese- und Schreibzugriffe getestet
werden. Dies bietet die Möglichkeit, die Festplatte vollständig auszulasten und die
Differenz des Stromverbrauches im Vergleich zum Leerlauf festzuhalten.
6.2.3 PassMark Software PerformanceTest 7.0
Diese Software ist für Benchmarks gedacht. Mittels Netzwerk-Tests kann eine
Netzwerklast zwischen zwei Teilnehmern generiert werden.
Seite 34 von 53
6.2.4 Microsoft Research Joulemeter 1.2
Joulemeter (Micorosft Research, 2011) ist eine Software von Microsoft Research,
welche die Leistungsaufnahme des Computers aufzeichnen kann. Microsoft
empfiehlt für die Benutzung der Software für Desktops die zusätzliche Hardware
„WattsUp Pro“. Diese hilft bei der Kalibrierung der Software. Ohne diese zusätzliche
Hardware muss die Kalibrierung manuell durchgeführt werden. Da diese zusätzliche
Hardware im Projekt nicht zur Verfügung stand, wurde das Programm für unsere
Hardware manuell parametrisiert (siehe Tabelle 10 ).
Kalibrierungsparameter
Grundlast
CPU Vollauslastung (Hochfrequenz)
CPU Vollauslastung (Niedrigfrequenz)
Monitor
Watt
67
24
7.2 (40%)
0
Tabelle 10: Kalibrierungsparameter Joulemeter
Die Werte für die Grundlast und CPU Volllast (Hochfrequenz) wurden gemessen. Die
CPU Vollauslastung (Niedrigfrequenz) kann nicht ohne „WattsUp Pro“ gemessen
werden. Der Wert wurde auf Anweisung der Joulemeter Community auf 40% der CPU
Vollauslastung (Hochfrequenz) gesetzt. Der Monitor wird ganz vernachlässigt und
somit auf 0 Watt parametrisiert.
Abbildung 22 Microsoft Joulemeter Leistungsaufnahme Computer
Seite 35 von 53
6.3 Messanalysen
Die Messungen wurden in unterschiedlicher Form durchgeführt. Pro Messung wird der
Ablauf kurz erläutert und anschliessend werden die Resultate ausgewertet.
6.3.1 EM 1
Für diese Messung wird der Computer gestartet und 10 Minuten im BIOS belassen. Um
die Leistung mit den Messungen aus den Szenarien 1-5 zu vergleichen, wurde der
gemessene Wert um den Faktor 6 multipliziert.
Zeit (Minuten)
10
60
Leistung (Wattstunden)
11.2
67.2
Tabelle 11 Resultate der erweiterten Messung 1
Grundsätzlich ist zu beobachten, dass der Computer im BIOS gleich viel Strom
braucht wie mit gestartetem Betriebssystem (mit Berücksichtigung der
Messabweichung). Ein gestartetes Betriebssystem wie Windows oder Ubuntu
verbraucht generell nicht mehr Strom als im BIOS, sondern über längere Zeit hin gar
weniger, da das Betriebssystem APCI unterstützt und nicht benötigte Geräte in den
Schlafmodus setzen kann. Einzig im Hintergrund gestartete Dienste (Updates, DeFragmentierung usw.) können eine Mehrauslastung des Computers verursachen.
6.3.2 EM 2
Die erweiterte Messung 2 ist so aufgebaut, dass die CPU Auslastung des Windows
Servers über zehn Minuten 100% beträgt. Während dieser Messung wurde mittels
Wattmeter die absolute Leistung gemessen. Die Software Joulemeter wird als Hilfe
dazu genommen, um den Verlauf der Messung besser zu analysieren.
Zeit (Minuten)
10
60
Ø (Joulemeter)
Leistung (Wattstunden)
15,1
90.6
90,66
Tabelle 12 Resultate der erweiterten Messung 2
Die maximale Leistungsaufnahme des Computers beträgt in diesem Szenario 91
Watt. Die durchschnittliche Leistungsaufnahme, welche mit Joulemeter gemessen
wurde, ist 90,66 W und deckt sich mit der Messung des Wattmeters.
Wird die Grundlast von 67 W von der maximalen Leistungsaufnahme subtrahiert,
kann die Leistungsaufnahme der CPU errechnet werden. Diese beträgt 24 Watt.
Somit bestätigt sich, dass der Computer unter Windows in Szenario 3 und 5 an die
Leistungsgrenze der CPU gestossen ist. Unter Ubuntu war dies nur in Szenario 5 der
Fall.
6.3.3 EM 3
Um den Einfluss einer ausgelasteten Festplatte auf den Leistungsverbrauch eines
Computers zu messen, wurde in dieser erweiterten Messung mittels Lese- und
Schreibzugriffen die Festplatte des Windows Servers vollständig ausgelastet. Mit dem
Seite 36 von 53
Programm Crystal Disk Mark wurde die Festplatte für ungefähr 3 Minuten (186
Sekunden) ausgelastet. Dafür wurden Dateien mit einer Grösse von 1 GB mehrmals
auf die Festplatte geschrieben und dann wieder gelöscht.
Abbildung 23 Festplattenauslastung mit Crystal Disk Mark
Mittels Joulemeter wurde der Verlauf der Leistungsaufnahme protokolliert und in
Abbildung 24 dargestellt.
71
Watt (Gesamtauslastung)
70
69
68
67
66
65
0
10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180
Zeit in Sekunden
Base (W)
Disk (W)
CPU (W)
Abbildung 24 Diagramm erweiterte Messung 3
Die unterste Schicht stellt die Grundauslastung dar und beträgt durchgehend 67
Watt. Zu beachten ist, dass die vertikale Achse bei 65 Watt beginnt. Die zweite
Schicht ist die Leistungsaufnahme der Disk, während die dritte Schicht die CPULeistungsaufnahme darstellt. Die Werte sind jeweils gestapelt aufsummiert.
Seite 37 von 53
Gesamtauslastung (W)
69.69
70.5
68.6
Durchschnitt
Maximal
Minimal
CPU (W)
0.50
1.9
0
Disk (W)
2.19
2.3
0.6
Tabelle 13 Resultate der erweiterten Messung 3
Aus Tabelle 13 ist ersichtlich, dass die Festplatte eine maximale Leistungsaufnahme
von 2.3 Watt aufweist. Zur durchschnittlichen Leistungsaufnahme der Festplatte von
2.19 Watt verbraucht die CPU zusätzlich 0.5 Watt, um die Festplatte mit den Daten zu
versorgen.
Gemäss den Erwartungen ist die Leistungszunahme bei voll ausgelasteter Festplatte
mit 2,3 Watt im Verhältnis zur CPU gering.
6.3.4 EM 4
Um den Einfluss der Netzwerkauslastung auf die Leistungsaufnahme zu verifizieren,
wurden in dieser Messung mithilfe des Tools Performancetest-Tool von PassMark
(siehe Kapitel 6.2.3) Daten vom Server (Messobjekt) zum Client transferiert. Dabei
wurde die CPU Auslastung mittels Microsoft Perfmon aufgezeichnet. Mit Joulemeter
wurde zusätzlich die Leistung der CPU inklusive Gesamtauslastung gemessen.
90
2.50
80
Leistung (Watt)
CPU Auslastung in %
60
1.50
50
40
1.00
30
20
Übertragene Daten in GB
2.00
70
0.50
10
0
0.00
0
20
40
60
80
100
120
140
160
180
Zeit in Sekunden
Gesamtauslastung (W)
CPU (W)
Prozessorauslastung (%)
Empfangene Daten (GB)
Abbildung 25 Diagramm erweiterte Messung 4
Seite 38 von 53
In Abbildung 25 ist zu erkennen, dass das Transferieren von Daten einen Einfluss auf
die CPU-Auslastung und die Leistungsaufnahme hat. Die durchschnittliche
Prozessorauslastung während der Messperiode betrug 40%, währenddessen wurden
1,98 GB Daten gleichmässig (11Mb/s) vom Client zum Server übertragen. Werden die
drei gemessenen Minuten auf 60 Minuten hochgerechnet, ergibt sich für die volle
Auslastung der Netzwerkkarte einen Verbrauch von 72 Wattstunden.
Zeit (Minuten)
3
60
Leistung (Watt)
3,6
72
Tabelle 14 Resultate der erweiterten Messung 4
Im Abbildung 25 ist nicht ersichtlich, wie viel Strom die Netzwerkverbindung effektiv
benötigt, da sich die Last des Netzwerks auf die CPU abwälzt. In Messungen von
(Gunaratne, Christensen, & Nordman, 2005) wurden drei verschiedene
Netzwerkkarten auf deren Stromverbrauch untersucht. Gemessen wurde der
Leistungsunterschied von 10Mb/s über 100Mb/s auf 1000Mb/s. Zwischen einer 10Mb/s
und 100Mb/s Netzwerkkarte ist die Leistungszunahme 0.3 W, von 10Mb/s auf
1000Mb/s ist dies 2.9 W (ohne Datenverkehr).
Somit kann nicht abschliessend definiert werden, wie gross der Stromverbrauch der
Netzwerkarte ist. Es wird angenommen, dass dieser bei 100Mb/s im Rahmen von 1-2
Watt liegt.
6.3.5 EM 5
In Szenario 5 wurden grosse Datenmengen von der Datenbank abgerufen und vor
dem Darstellen auf einer Webseite im Code gefiltert. Die enormen Datenmengen
brachten den Server an das Leistungslimit. Speziell im Zusammenhang mit
Datenbanken ist oftmals viel Optimierungspotential vorhanden. In der folgenden
erweiterten Messung wird die Filterung der Daten mithilfe eines SQL Statements
anstelle einer If-Abfrage in der While-Schleife im Code erledigt. Die Anzahl
zurückgegebener Datensätze minimiert sich von 100‘000 auf 1‘000 und analog
reduziert sich die Anzahl Durchläufe in der Schleife. Angezeigt werden bei dieser
Messung, wie auch bei Szenario 5, exakt 1‘000 Datensätze. Gemäss der
Erwartungshaltung sollte sich die Leistungsaufnahme verringern, da die jeweiligen
Codestellen 90‘000 mal weniger durchlaufen werden müssen. Der Datenbankserver
wird kaum mehr Last generieren, da dieser ebenfalls weniger Daten pro Abfrage
liefern muss.
Folgendes PHP Script wurde minimal für die Messung angepasst:
1. Hinzufügen von SQL Where-Statement
2. Löschen der If-Abfrage
Seite 39 von 53
where Text = ". $_GET["Text"]
Abbildung 26 Codeausschnitt erweiterte Messung 5
Die Messung wurde 10 Minuten lang mit derselben Ausgangslage wie in Szenario 5
unter Ubuntu ausgeführt. Tabelle 15 zeigt die Resultate von EM5 im Vergleich zu
Szenario 5.
Zeit (Minuten)
10
60
Szenario 5 (SQL Filter)
11.3
67.8
Szenario 5 (Code Filter)
88.9
Tabelle 15 Resultate der erweiterten Messung 5
Auf 60 Minuten hochgerechnet verbrauchte der Computer 67.8 Watt. Somit ist die
Leistungsaufnahme um 21.1 Watt (23.7%) niedriger als in Szenario 5.
Seite 40 von 53
140
2'500
32.7%
120
2'000
Stromverbrauch in Prozent
1'500
80
60
1'000
100%
Antwortzeit in ms
1.2%
100
100%
40
500
20
0
0
Szenario 5
Erweiterungmessung 5
Mehr-Stromverbrauch (in %)
Stromverbrauch Szenario 1 ≙ 100%
Durchschnittliche Antwortzeiten
Abbildung 27 Vergleich Szenario 5 mit erweiterter Messung 5
Abbildung 27 zeigt Szenario 5 und die Erweiterungsmessung 5 auf Basis von Szenario
1. Während der Mehrstromverbrauch von Szenario 5 noch bei 32.7% lag, ist es bei
EM5 nur noch 1.2% Mehrstromverbrauch gegenüber Szenario 1. Die Filterung der
Daten mit SQL ist deutlich stromsparender als die Filterung im Code.
Entsprechend der Leistungsaufnahme sind auch die durchschnittlichen
Antwortzeiten der beiden Messungen sehr unterschiedlich. Die Filterung mit SQL ist
nicht nur stromsparender, sondern auch deutlich performanter als die Filterung im
Code. Während die durchschnittliche Antwortzeit in Szenario 5 noch 2195
Millisekunden betrug, sind es in der erweiterten Messung 5 noch 20 Millisekunden.
Messung
Szenario 5
Erweiterte Messung 5
Durchschnittliche Antwortzeit in ms
2195
20
Tabelle 16 Durchschnittliche Antwortzeiten im Vergleich
Seite 41 von 53
6.3.6 EM 6
Während der zehnminütigen Messung wurde der Windows Server mit einer
steigenden Anzahl Anfragen belastet, sodass am Ende der Messung alle 40 Benutzer
gleichzeitig Anfragen an den Webserver stellten. Die Anfragen sind dieselben wie in
Szenario 5 (Hohe Datenmenge und Filterung der Daten im Code).
Zeit (Minuten)
10
60
Ø (Joulemeter)
Leistung (Watt)
13,6
81.6
81.03
Tabelle 17 Resultate der erweiterten Messung 6
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
Die effektiv gemessene Leistungsaufnahme mit dem physischen Messgerät
Wattmeter weicht nur minim von der durchschnittlichen Leistungsaufnahme
gemessen mit Joulemeter ab. Wird der Messfehler von 0.5% miteinbezogen, ist die
Differenz noch 0.162 Watt. Für die weitere Analyse des Stromkonsums werden die mit
Joulemeter gemessenen Werte verwendet.
4.5
90
4
80
3.5
70
3
60
2.5
50
2
40
1.5
30
20
1
10
0.5
0
Anfragen pro Sekunde (Hits)
Prozessorauslastung [%]
Stromkonsum [Watt]
100
0
0
1
1.5
2.5
3.5
4
5
6
6.5
7.5
8.5
9
10
Vergangene Zeit in Minuten
Anfragen pro Sekunde
8 Periode gleit. Mittelw. (Prozessorauslastung in %)
8 Periode gleit. Mittelw. (Stromkonsum (Watt))
Abbildung 28 Messverlauf erweiterte Messung 6
Die schwarze Linie in Abbildung 28 zeigt den Stromverbrauch im gleitenden
Mittelwert auf. Dieser steigt kontinuierlich von 67 W auf 91 W an. Auffällig ist der
Zusammenhang zwischen der CPU Auslastung (Grüne Linie) und der Anzahl Anfragen
pro Sekunde (Blaue Linie). Diese verlaufen parallel zueinander und erreichen am
Ende eine gemeinsame Abflachung, da die Leistungsgrenze erreicht wurde. Damit ist
ersichtlich, dass die Anzahl Anfragen pro Sekunde und die Leistung des Systems
zueinander in linearer Beziehung stehen.
Seite 42 von 53
Ob sich nun auch der Stromverbrauch linear zur CPU Auslastung verhält, zeigt
Abbildung 29. Die grüne Linie zeigt die Prozessorauslastung in %, die schwarze Linie
den Stromverbrauch in % (100% ist dabei die maximale Leistungsaufnahme des
Computers). Um die stark schwankenden Messwerte sprechend darzustellen, wurde
ebenfalls ein gleitender Mittelwert benutzt.
140
120
100
80
60
40
20
0
0
1
1.5
2.5
3.5
4
5
6
6.5
7.5
8.5
9
Vergangene Zeit in Minuten
Linear (Prozessorauslastung in %)
10 Periode gleit. Mittelw. (Prozessorauslastung in %)
Linear (Stromverbrauch in %)
10 Periode gleit. Mittelw. (Stromverbrauch in %)
Abbildung 29 EM 6 Zusammenhang CPU und Stromverbrauch
Während die CPU Auslastung gleichmässig und kontinuierlich von 0 auf 100% steigt,
steigt auch der Stromverbrauch stetig an. Trotz mehreren Schwankungen stabilisiert
sich der Stromverbrauch nach 8,5 Minuten auf dem Maximum. Die Leistungsgrenze
der CPU wurde erreicht.
In der Grafik ist eine Linearität zwischen CPU Auslastung und Stromverbrauch zu
erkennen. Die beiden linearen, gestrichelten Linien sind sogenannte Trendlinien,
welche eine lineare Funktion über sämtliche Messwerte definieren.
6.3.7 EM 7
Die Reduktion von 100'000 auf 50‘000 Datensätze resultierte für beide Server in einer
geringeren Antwortzeit, sowie einem geringeren Stromverbrauch als noch in Szenario
5. Wiederum ist die durchschnittliche Antwortzeit des Ubuntu Servers tiefer als
diejenige des Windows Servers. In Szenario 5 waren es 35% tiefere, in dieser
erweiterten Messung mit weniger Last fast 40% tiefere Antwortzeiten, wie in Tabelle 18
abzulesen ist. Somit bestätigt diese erweiterte Messung die Resultate von Szenario 5.
Seite 43 von 53
10
Die Performance des Windows Servers ist in Szenario 5 somit deutlich schlechter als
diejenige des Ubuntu Servers.
Messung
Stromverbrauch
Ø Antwortzeit
Antwortzeit (% zu
Windows Server)
Ubuntu Server
81.6 Wh
186 ms
Windows Server
82.2 Wh
309 ms
60.19%
100%
Tabelle 18 Resultate der erweiterten Messung 7
6.4 Auswertungen
Werden die Messungen von Szenario 1 sowie den erweiterten Messungen 2 und 3
kombiniert, erhält man ein Gesamtbild des Stromverbrauches des Windows Servers
unter Volllast. Der Stromverbrauch setzt sich in dieser Zusammenstellung nur aus der
Grundlast, der CPU und der Disk zusammen. Abbildung 30 ist so zu verstehen, dass
die Grundlast den Leerlauf des Systems wiederspiegelt. Mittels vollständiger
Auslastung der Festplatte und CPU weist der PC einen Stromverbrauch von maximal
93.3 W auf. Als Kontrast dazu dient die Leistungsaufnahme vom Standby-Modus. Dort
bezieht der Computer noch immer 2.1 W. Ein Teil dieser Energie wird von der
Netzwerkkarte benötigt, da diese trotz heruntergefahrenem System weiterläuft.
100
90
80
2.3 W
24 W
70
Watt
60
50
40
67 W
30
20
10
2.1 W
0
Vollauslastung
Standby
Grundsystem
CPU
Disk
Abbildung 30 Leistungsaufnahme des Computers unter Volllast und im Standby
Seite 44 von 53
2.5%
25.7%
71.8%
Grundsystem
CPU
Disk
Abbildung 31 Prozentuale Leistungsaufnahme des Systems unter Volllast
Wird die Vollauslastung als 100% betrachtet, beträgt der Anteil der Grundlast der
eingesetzten Hardware am Stromverbrauch 71,8%. Nebst der Grundlast hat die CPU
mit 25.7% den deutlich höheren Anteil als die Disk mit 2.5%. Unter Berücksichtigung
der gegebenen 71.8% Grundlast kann mittels Software auf der Versuchshardware
noch maximal 28.2% (26.3 Wattstunden) zusätzliche Energie verbraucht respektive
gespart werden.
Seite 45 von 53
7 Fazit
Durch die verschiedensten Messungen konnten in dieser Arbeit unterschiedliche
Aspekte in Bezug auf Green IT festgestellt werden. Einerseits wurde ein Vergleich der
Energieeffizienz von Windows Server 2008 R2 mit Ubuntu Server 11 gemacht,
andererseits die Performance von Webservern mit deren Leistungsbedarf verglichen.
Die Messungen lassen für den untersuchten Bereich folgende Aussagen zu:
Die Grundlast eines Systems (Computer, Server), das heisst die Leistungsaufnahme im
Leerlauf, besitzt den deutlich grösseren Anteil am Stromverbrauch als die eigentliche
Last. So beträgt die Grundlast 62% eines voll ausgelasteten Systems. Generell sollte
deshalb darauf geachtet werden, dass die eingesetzte Hardware eine niedrige
Grundlast aufweist. Die Seite www.energystar.ch gibt einen guten Überblick über
den Stromverbrauch aktueller Hardwaremodelle. Die Liste der Hardwaremodelle
beinhaltet keine Serverhardware.
Bei den Szenarien 1-5 wurden sämtliche Messungen auf zwei unterschiedlichen
Betriebssystemen gemacht. Für die gemachten Messungen kann gesagt werden,
dass die Wahl des Betriebssystems keine Rolle gespielt hat. Entscheidender war der
Einsatz der Software auf dem Betriebssystem. Beispielsweise konsumierte das CMS
DotNetNuke deutlich mehr Strom als Joomla.
In weiteren Messungen konnte festgestellt werden, dass die Performance eines
Systems eng in Zusammenhang mit dessen Leistungsaufnahme steht. Für ein CMS auf
einem Webserver sieht dies folgendermassen aus: Je schneller ein System die
gestellten Anfragen bearbeiten kann, desto effizienter ist das entsprechende CMS
und desto energieeffizienter kann die Anfrage bearbeitet werden. Unter dem Strich
resultiert für das CMS mit den kleineren Antwortzeiten ein geringerer Stromverbrauch.
Somit kann es sich lohnen, den Webserver mittels Stresstest zu belasten, um Auskunft
über dessen Performance zu erhalten. Bei wiederkehrenden Tests kann die
Performance verglichen werden, um beispielsweise den Einfluss von
Weiterentwicklungen am CMS zu messen.
Weiter wurde in den Messungen festgestellt, dass das Zusammenspiel von Webseite
und Datenbank entscheidend für die Performance ist. Die Datenbankabfragen
sollten gezielt und möglichst effizient gestaltet werden, damit die Daten so
ankommen, wie sie auf der Webseite präsentiert werden sollen. Mithilfe der
Optimierung von Datenbankabfragen kann die Last gesenkt werden. Im Fall der
erweiterten Messung 5 (optimiertes Szenario 5) waren es 21.1 Wattstunden
beziehungsweise 23,7%, die im Vergleich zu Szenario 5 eingespart werden konnten.
Zwar beträgt der Anteil der Grundlast an einem voll ausgelasteten System ganze
62%, trotzdem kann mittels einer effizienten Programmierung einer Anwendung, wie
die Optimierung von Szenario 5 in der erweiterte Messung 5, fast ein Viertel des
ursprünglichen Energiebedarfs eingespart werden.
Mittels effizienter Software ist es somit möglich, Energie zu sparen. Nebst dem
verwendeten CMS zeigte sich auch ein Unterschied bei der darunterliegenden
Seite 46 von 53
Webserverplattform. Apache mit MySQL und PHP erwies sich als stromsparender und
performanter als der IIS mit MSSQL und ASP.NET. Die Antworten vom Apache
Webserver wurden in den Messungen 35-40% schneller beantwortet. Dies bedeutet
jedoch nicht automatisch, dass ein ASP.NET CMS generell mehr Strom verbraucht als
ein PHP CMS, da die Programmierung des CMS mehr Einfluss auf die
Leistungsaufnahme hat, als die darunterliegende Technologie.
Seite 47 von 53
8 Glossar
Begriff
Apache
Cloud Computing
Erklärung
Weit verbreitete Open-Source-Software für Webserver
Bereitstellung von Computerhardware und -software auf externen
Servern meist im Internet, welche nach Nutzung verrechnet und
gemietet werden können.
CMS
Datacenter Infrastructure
Efficiency (DCiE)
Ein Content Management System ist ein Webapplikationsframework
Bewertung des Wirkungsgrades der im Datenzentrum eingesetzten
Energie
Berechnung: 1/PUE
IIS
Internet Information Server, Standard Webserver auf Microsoft
Windows Server
LAMP-Server
Kombinierten Einsatz von Linux, Apache, MySQL und PHP auf einem
System
Multithreading
Gleichzeitiges Abarbeiten mehrerer Threads innerhalb eines einzelnen
Prozesses
Power Usage Effectivness
(PUE)
Ermittlung der Effizienz des Energieeinsatzes
Berechnung: Energieverbrauch aller IT-Geräte / Gesamtenergie des
Rechenzentrums
Prozessor WakeUps
Thin Client
Übergang des Prozessors vom Schlaf- zum Rechenzustand
Abgespeckte Endgeräte (Terminals), welche im Netzwerk als
Arbeitsplatz dienen.
Thread
Ubuntu
Virtualisierung
Teil eines Prozesses
Freie und kostenlose Linux-Distribution, auf Debian basierend
Die Abstraktion von logischen Systemen von deren physischer
Implementierung
Seite 48 von 53
9 Abbildungsverzeichnis
Abbildung 1 Titelbild Green IT (Quelle: http://www.ilmforum.de/wpcontent/uploads/2010/12/greenit2.jpg) .............................................................................. 1
Abbildung 2 2000 Watt-Gesellschaft (Novatlantis) ............................................................. 6
Abbildung 3 Logo The Green Grid (Grid) ............................................................................. 7
Abbildung 4 Anteil der Komponenten am Stromverbrauch eines Laptops mit
Windows 7 (Sinofsky, 2009)...................................................................................................... 8
Abbildung 5 Verteilung des Energieverbrauchs eines durchschnittlichen Servers
(Anderson, 2007) ...................................................................................................................... 9
Abbildung 6 Weltweite Kosten für die Energie sowie Kühlung von Servern (Michel) ... 10
Abbildung 7 Energieverbrauch eines Rechenzentrums, Daten von (IDG Business
Media GmbH, 2009) .............................................................................................................. 10
Abbildung 8 Green IT-Massnahmen der Gebäudeversicherung Bern (Koch, 2011) ... 13
Abbildung 9 Versuchsaufbau physikalisch ......................................................................... 16
Abbildung 10 Top 10 Webserver (NetObservatory, 2011) ................................................ 18
Abbildung 11 Top 10 CMS (NetObservatory, 2011) .......................................................... 18
Abbildung 12 Eingabemaske der Parametrisierung des Webserver Stress Tools .......... 19
Abbildung 13 Szenario 2: Einfache ASP/PHP Webseite .................................................... 22
Abbildung 14 Szenario 3: Startseite von Joomla ............................................................... 23
Abbildung 15 Szenario 3: Startseite von DotNetNuke ....................................................... 23
Abbildung 16 Szenario 5: Schreiben von einem Datensatz ............................................. 24
Abbildung 17 Szenario 5: Lesen von Datensätzen ............................................................ 24
Abbildung 18 Szenario 5: Lesen von Datensätzen ............................................................ 24
Abbildung 19 Szenario 3: Antwortzeiten der beiden CMS ............................................... 26
Abbildung 20 Antwortzeiten der Leseoperation (Windows/Ubuntu) ............................. 27
Abbildung 21 Stromverbrauch und Antwortzeiten der Szenarien 2 bis 5 im Überblick 30
Abbildung 22 Microsoft Joulemeter Leistungsaufnahme Computer ............................. 35
Abbildung 23 Festplattenauslastung mit Crystal Disk Mark.............................................. 37
Abbildung 24 Diagramm erweiterte Messung 3 ................................................................ 37
Abbildung 25 Diagramm erweiterte Messung 4 ................................................................ 38
Abbildung 26 Codeausschnitt erweiterte Messung 5 ....................................................... 40
Abbildung 27 Vergleich Szenario 5 mit erweiterter Messung 5 ....................................... 41
Abbildung 28 Messverlauf erweiterte Messung 6 .............................................................. 42
Abbildung 29 EM 6 Zusammenhang CPU und Stromverbrauch ..................................... 43
Abbildung 30 Leistungsaufnahme des Computers unter Volllast und im Standby ...... 44
Abbildung 31 Prozentuale Leistungsaufnahme des Systems unter Volllast ................... 45
Seite 49 von 53
10 Tabellenverzeichnis
Tabelle 1 ACPI Stromsparmodi (ACPI, 2010) (Wikipedia, 2011) ....................................... 11
Tabelle 2 ACPI Schlafmodus (ACPI, 2010) (Wikipedia, 2011)........................................... 11
Tabelle 3 Christ CLM210 (Christ Elektronik, 2005) ............................................................... 16
Tabelle 4 Fluke 298 Multimeter (Fluke) ................................................................................ 16
Tabelle 5 Fluke i200 Wechselstromzange (Fluke) ............................................................... 17
Tabelle 6 Webserver Stress Tool - Test Spezifizierung ......................................................... 20
Tabelle 7 Messresultate Szenario 1-5 ................................................................................... 25
Tabelle 8 Berücksichtigung des Messfehlers in Szenario 2 ................................................ 26
Tabelle 9 Wertetabelle Vergleich Szenario 2 -5 ................................................................. 31
Tabelle 10: Kalibrierungsparameter Joulemeter ............................................................... 35
Tabelle 11 Resultate der erweiterten Messung 1 ............................................................... 36
Tabelle 12 Resultate der erweiterten Messung 2 ............................................................... 36
Tabelle 13 Resultate der erweiterten Messung 3 ............................................................... 38
Tabelle 14 Resultate der erweiterten Messung 4 ............................................................... 39
Tabelle 15 Resultate der erweiterten Messung 5 ............................................................... 40
Tabelle 16 Durchschnittliche Antwortzeiten im Vergleich ................................................ 41
Tabelle 17 Resultate der erweiterten Messung 6 ............................................................... 42
Tabelle 18 Resultate der erweiterten Messung 7 ............................................................... 44
Seite 50 von 53
11 Literaturverzeichnis
ACPI. (05. April 2010). Advanced Configuration and Power Interface Specification,
Revision 4.0a.
Aebischer, B. (27. September 2011). Der Beitrag von Green ICT zur Energiewende,
Facts and Vision. Abgerufen am 29. September 2011 von http://greenit.si.ch/media/archive1/lifefair2011/Aebischer_GreenIKTEnergiewende_270911.p
df
Anderson, N. (2007). ars technica, New industry group looks to cut server room power
consumption. Abgerufen am 05. Oktober 2011 von
http://arstechnica.com/old/content/2007/02/8932.ars
Christ Elektronik. (April 2005). CLM200, CLM210, CLM221. Abgerufen am 03.
November 2011 von http://www.christelektronik.de/shop/Messgeraete/Leistungsmessgeraete/CLM200,%20CLM210,
%20CLM221/
ETH Zürich. (06. Mai 2010). ETH, Aquasar ist in Betrieb. Abgerufen am 05. Oktober 2011
von http://www.ethz.ch/media/detail?pr_id=986
European Comission. (10. Oktober 2011). The EU climate and energy package.
Abgerufen am 29. September 2011 von
http://ec.europa.eu/clima/policies/package/index_en.htm
Fluke. (kein Datum). Messgeräte von Fluke. Abgerufen am 25. November 2011 von
http://www.fluke.com
Golem. (kein Datum). Cloud Computing - Golem.de. Abgerufen am 29. September
2011 von http://www.golem.de/specials/cloud-computing/
Grid, T. G. (kein Datum). Energy Efficient Data Center Design - PUE, DCIE, ERE - The
Green Grid. Abgerufen am 30. September 2011 von
http://www.thegreengrid.org/
Gunaratne, C., Christensen, K., & Nordman, B. (2005). Managing energy
consumption costs. Abgerufen am 15. Dezember 2011 von Department of
Computer Science and Engineering:
http://www.csee.usf.edu/~christen/energy/ijnm05.pdf
Holzmann, S. (16. August 2011). Forum Nachhaltig Wirtschaft, Was wurde eigentlich
aus... Green IT? Abgerufen am 29. September 2011 von
http://www.nachhaltigwirtschaften.net/scripts/basics/ecoworld/wirtschaft/basics.prg?a_no=4703
HP. (29. Oktober 2008). HP Compaq dc7700 Business PC. Abgerufen am 03.
November 2011 von
http://h18000.www1.hp.com/products/quickspecs/12543_na/12543_na.HTML
Seite 51 von 53
IDG Business Media GmbH. (26. März 2009). Computerwoche, Wie Unternehmen
Kosten senken können. Abgerufen am 29. September 2011 von
http://www.computerwoche.de/hardware/data-centerserver/1891186/index3.html
JS-Projects UG. (18. April 2011). IT-INFTECH, Green IT – Begriff und Chancen durch
nachhaltige IT. Abgerufen am 22. September 2011 von http://www.itinftech.de/hardware/green-it-begriff-und-chancen-durch-nachhaltige-it/
Koch, B. (27. September 2011). SI Fachgruppe Green IT. Abgerufen am 29.
September 2011 von http://greenit.si.ch/media/archive1/lifefair2011/Koch_CloudComputing_270911.pdf
Larson, P. (Mai 2009). Power Efficiency – Analysis and SW Development. Abgerufen
am 30. September 2011 von http://software.intel.com/file/15306
Michel, D. B. (kein Datum). Fachgruppe Green IT, Green IT für eine nachhaltige Welt.
Abgerufen am 29. September 2011 von http://greenit.si.ch/media/archive1/lifefair2011/Michel_EffizienteRechenzentren_270911.pdf
Micorosft Research. (2011). Joulemeter: Computational Energy Measurement and
Optimization. Abgerufen am 1. Dezember 2011 von
http://research.microsoft.com/en-us/projects/joulemeter/default.aspx
NetObservatory. (30. Juni 2011). NetObservatory - NORA 2011 Q2. Abgerufen am 07.
Oktober 2011 von https://www.netobservatory.ch/public/en/nora/pdf_files
Novatlantis. (kein Datum). 2000-Watt-Gesellschaft. Abgerufen am 29. September
2011 von Die 2000-Watt-Gesellschaft:
http://www.novatlantis.ch/2000watt.html
Paessler AG. (kein Datum). Webserver Stress Tool. Abgerufen am 14. Oktober 2011
von http://www.paessler.com/webstress
Pettey, C. (26. April 2007). Gartner Newsroom, Gartner Estimates ICT Industry
Accounts for 2 Percent of Global CO2 Emissions. Abgerufen am 22.
September 2011 von http://www.gartner.com/it/page.jsp?id=503867
Sinofsky, S. (6. Januar 2009). Engineering Windows 7. Abgerufen am 30. September
2011 von hrom
SWICO. (kein Datum). Was ist ENERGY STAR? Abgerufen am 22. Dezember 2011 von
Energy Star: http://www.energystar.ch/ueber/ueber_was.asp
ubuntuusers.de. (12. Mai 2011). Server Installation. Abgerufen am 13. Oktober 2011
von http://wiki.ubuntuusers.de/server_installation
water & stone. (27. November 2011). Opne Soruce Market CMS Share Report.
Abgerufen am 30. November 2011 von
Seite 52 von 53
http://www.waterandstone.com/downloads/2011OSCMSMarketShareReport.
pdf
Wikipedia. (01. August 2011). Advanced Configuration and Power Interface.
Abgerufen am 29. September 2011 von
http://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
Wikipedia. (16. September 2011). Wikipedia, Thin Client. Abgerufen am 30.
September 2011 von http://de.wikipedia.org/wiki/Thin_Client
Seite 53 von 53