von Dietmar Veröffentlicht in Allgemein, Fachchinesisch

Nach den gestern veröffentlichen Punkten

1) Reduzierung von HTTP-Requests
2) Javascript und CSS zusammenfassen, “minifizierien” und komprimieren
3) Bilder verkleinern/skalieren und optimieren
4) Grafiken und Icons zusammenfassen / Spriting

nehmen wir uns heute die nachfolgenden Themen vor:

5) Caching
6) Kompression einsetzen – GZIP/DEFLATE
7) Weitere gesammelte Empfehlungen in Kurzform
8) Die eigene Webseite testen

5) Caching

Gemeint ist damit der Cache des Browsers. Viele Anwendungen bringen bereits eine Option zur Aktivierung/Konfiguration von Cache-Werten mit und setzen dann entsprechende Optionen automatisch in einer .htaccess-Datei. Relevant sind v.a. das Caching von Bildern, CSS- und Javascript-Dateien.

Das nachfolgenden Beispiel zeigt, wie eine .htaccess-Datei aussehen kann. Es wird zunächst geprüft, ob das für die Cachesteuerung benötigte Modul auf dem Webserver installiert ist. Nur wenn dies der Fall ist, wird die Option zum manuellen ansteuern der Cache-”Befehle” aktiviert (ExpiresActive on). Mittels ‘ExpiresDefault’ wird ein Standardwert gesetzt, der für alle Dateien Gültigkeit besitzt.

Im Beispiel sollen alle Dateien nach dem Zugriff fünf Minuten lang im Browsercache gehalten werden. Anschließend folgt eine Einschränkung bzw. genauere Definierung für einzelne Dateitypen, die dann teilweise länger oder kürzer bzw. gar nicht im Cache verbleiben sollen. Es sind auch exaktere Angaben möglich wie z.B. “access plus 1 month 19 days 2 hours 8 minutes”.

Bitte beachten Sie, dass die nachstehenden Werte nur der Veranschaulichung dienen und keine allgemein gültige Empfehlung für die Nutzung mit Ihrer Webseite darstellen!

<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 5 minutes"
ExpiresByType image/ico "access plus 1 year"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/html "access plus 4 hours"
ExpiresByType text/htm "access plus 4 hours"
ExpiresByType text/javascript "access plus 2 days"
ExpiresByType text/css "access plus 2 days"
ExpiresByType text/xml "access plus 2 days"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType text/cache-manifest "access plus 0 seconds"
</IfModule>

Bei nicht aufgeführten Dateien gilt der Standard-(Default)-Wert. Wird für mehrere Typen der selbe Zeitraum vergeben, so können diese auch zusammengefasst werden, beispielsweise:

ExpiresByType image/jpg image/jpeg image/gif image/png "access plus 1 month"

Alle Details der Konfigurationsmöglichkeiten finden sich in der Apache-Doku zu mod_expires .

6) Kompression einsetzen – GZIP/DEFLATE

Um die Menge an Daten, die bei der Übertragung zwischen Server und Browser anfällt, zu verkleinern, besteht die Möglichkeit der Kompression von Dateien per GZIP. Diese kann per Skript erfolgen oder über das sog. deflate-Modul des bei uns eingesetzten Apache-Webservers.

Auch die dafür erforderliche Aktivierung und Konfiguration wird in der .htaccess-Datei vorgenommen und es müssen explizit die Typen angegeben werden, die komprimiert übertragen werden sollen. Auch hierbei ist es möglich, mehrere Einträge einfach nacheinander anzugeben oder jeweils einzeln in einer Zeile:

<IfModule mod_headers.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript application/x-javascript
</IfModule>

Ein ‘Default’ für alle Dateien ähnlich wie für den Cache existiert ebenfalls. Sollen alle MIME-Typen des Dokuments in komprimierter Form übertragen werden, so kann anstelle der jeweils einzelnen Zeilen einfach die folgende genutzt werden:

SetOutputFilter DEFLATE

Wichtig: Da nicht alle Browser die Kompression unterstützen, sollten dafür Ausnahmen angegeben werden. Die nachfolgende erste Zeile nimmt alle Netscape-Browser der Version 4.06, 4.07 und 4.08 komplett aus, die zweite Zeile führt dazu, dass an alle InternetExplorer kleiner der Version 7 nur html-Inhalte komprimiert übertragen werden. Details der Konfigurationsmöglichkeiten finden sich in der Apache-Doku zu mod_deflate .

BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html

 

7) Weitere gesammelte Empfehlungen in Kurzform

  • CSS-Dateien sollten zu Beginn geladen und deshalb die Pfade dazu im <head>-Bereich angegeben werden
  • Erforderliche Schriften ebenfalls innerhalb der <head>-</head>-Attribute, sofern Sie nicht per CSS genutzt/definiert werden
  • Redirect-Anweisungen in der .htaccess sind nach Möglichkeit zu vermeiden und auf ein Minimum reduzieren. Hintergrund: Jede Umleitung ist wieder eine neue Anfrage (HTTP-Request) an den Webserver.
  • Alle Javascript-Dateien aus dem Quelltext an das Ende unmittelbar vor das schließende stellen, damit der Browser mit der Darstellung der Webseite nicht warten muss, bis alle Javascript-Dateien geladen wurden.
  • Bilder später nachladen; beispielsweise erst beim scrollen die weiter unten eingebundenen Grafiken vom Webserver anfordern. Für jQuery existiert ein Plugin: Lazy Load Plugin for jQueryDas Gegenteil von Lazy-Loading wäre das Preloading, also das Laden von Bildern bevor die Seite aufgebaut wurde. Beide Varianten haben Ihre Berechtigung und sind vom gewünschten Ergebnis abhängig. Bei Seiten mit nur wenig HTTP-Requests beispielsweise einer Landing Page oder einer Micro-Site, kann das Preloading als Option genutzt werden.
  • Nutzen Sie einen ManagedServer oder einen ResellerDedicated-Server bei uns, so können Sie optional “KeepAlive” für den Server aktivieren lassen. KeepAlivesorgt dafür, dass jede aufgebaute Verbindung zum Webserver offen gehalten wird und so kein neuer Verbindungsaufbau erforderlich ist. Der Performancegewinn ist je nach Webseite/Dienst aber nur marginal.Die Werte für KeepAlive können auf Wunsch auch verändert werden, wir setzen derzeit standardmäßig folgende Werte :
    - MaxKeepAliveRequests 100
    - KeepAliveTimeout 5 (Dieser Wert sollte nicht zu hoch werden werden, da ansonsten die offenen Socket-Verbindungen über längere Zeit ungenutzt im Warte-Modus verbringen und die Anzahl der möglichen Verbindungen schnell aufgebraucht wird)

8) Die eigene Webseite testen

Die nachfolgend verlinkten Seiten führen verschiedene Messungen aus, die die bisher genannten Punkte prüfen und auf Optimierungspotential hinweisen. Die Ergebnisse werden zwar genauer erklärt, allerdings wird im Regelfall auf englischsprachige Erläuterungen verwiesen. Die Prüfroutinen ähneln sich sehr stark, da Sie bei der Gewichtung der Ergebnisse auf die Empfehlungen des Google Page Speed Grade und des YSlow Grade von Yahoo zurückgreifen. Diese beiden unterscheiden sich jedoch in Ihrer Gewichtung einzelner Punkte.

Browserplugins:

Auch bei den Onlinetests darf nicht vergessen werden, dass es abhängig Ihres Anwendungsfalls nicht immer sinnvoll ist, alle Punkte umzusetzen. Hat man einen Großteil einmal umgesetzt, so sind die verbleibenden Punkte meist nur mit einem deutlich höheren Aufwand realisierbar und das Verhältnis der Kosten/Nutzen verlagert sich stark auf die Kostenseite.

Abschließend möchten wir noch erwähnen, dass die genannten Informationen nur eine Auswahl an Ansätzen darstellen und die Kombinationsmöglichkeiten vielfältig sind. Nicht in jedem Fall können alle Punkte berücksichtigt werden.

 

Schlagworte:
von Dietmar Veröffentlicht in Allgemein, Fachchinesisch

Im Oktober haben wir mit dem Beitrag “Die Ladezeit von Webseiten verbessern” 5 einfache Tipps gegeben, die Einfluss darauf nehmen können, dass Webseiten schneller geladen werden.

In den Kommentaren gab es zahlreiche weitere und auch grundlegende Empfehlungen sowie den Wunsch, das Thema etwas genauer und detaillierter zu erläutern. Diesem Wunsch kommen wir nun gerne nach und splitten das Thema aufgrund des Umfangs in zwei Beiträge auf.

1) Reduzierung von HTTP-Requests

Verringern Sie die Anzahl an Dateien, die beim Aufruf geladen werden. Dazu zählen Bilder, CSS, Skripte von Facebook, Twitter, einer Chatbox, Statisktiksoftware, Flash und andere Videos etc. Setzen Sie einen Shop, Blog oder ein CMS sein, so nutzen Sie dafür sicher die eine oder andere Erweiterung. Viele Erweiterungen bringen, ebenso wie Templates eigene CSS- und/oder Javascript Dateien mit, die dann zusätzlich bei jedem Aufruf der Webseite geladen werden müssen. Das führt uns direkt zum nächsten Punkt:

2) Javascript und CSS zusammenfassen, “minifizierien” und komprimieren

Verzichten Sie soweit möglich auf Erweiterungen, die eigene CSS-Dateien und/oder Javascript-Bibliotheken mitliefern, und fassen Sie die zu ladenden Dateien zusammen.

J(ava)S(cript) und CSS können “minified” (Bedeutung eigtl. herabgesetzt) werden und sind dadurch komprimierter. Es werden Leerstellen, Einrückungen, Kommentare und Zeilenumbrüche im Quelltext eingespart, allerdings verringert sich dadurch auch die Lesbarkeit des Codes. Für die “Minifizierung” existieren verschiedene Tools und für beliebte OpenSource-Applikationen auch fertige Plugins sowie Online-Kompressoren.

Wird jQuery als Javascript-Bibliothek eingesetzt, so wirkt sich der Einsatz verschiedener Versionen wie folgt auf die Größe und zu übertragende Datenmenge aus:

jQuery Version 1.8.3

  • Normal (261 KB)
  • Minified (91.40 KB)
  • GZIP (76.81 KB)
  • Minfied+GZIP (33.43 KB)

Das Komprimieren der Inhalte wird in diesem Fall im englischen als ‘to minify’ (“Minifizieren”) bezeichnet, sollte aber nicht mit dem in der deutschen Sprache ebenfalls verwendeten Begriff des Komprimierens im Sinne der Kompression verwechselt werden. Letztere bezeichnet eigentlich das Verfahren der Datenkomprimierung beispielsweise mittels dem Kompressionsprogramm gzip.

Die Begriffe werden oft gemeinsam verwendet, spricht man von der Komprimierung von JS- oder CSS-Dateien ist jedoch meistens nur das “to minify” gemeint, da die Kompression mittels einem Kompressionsverfahren separat behandelt wird. Auch wir kommen später noch genauer darauf zu sprechen.

3) Bilder verkleinern/skalieren und optimieren

Bilder sollten in dem Format auf dem Server liegen, in dem sie später auch ausgegeben werden sollen. Ein 1024×684 Pixel großes Bild, das auf der Webseite nur für einen Teilbereich als Vorschaubild genutzt wird, sollte nicht über den Quelltest verkleinert werden, denn es muss das Orginalbild, das bedeutend größer ist, vom Server angefordert werden. Die Angabe der HTML-Größenattribute “width” und “height” sollte aber dennoch genutzt werden, denn dadurch reserviert der Browser direkt den Platz für das Bild und muss nach dem Laden des Bildes die Seite nicht erneut aufbauen (rendern).

Das Optimieren von Bildern durch die Entfernung von Metaangaben, Zusammenfassung von Farbwerten etc. ist mittlerweile nahezu ohne Qualitätsverlust möglich und führt zu einer kleineren Datei. Da es aber keine absolut verlustfreie Optimierung/Komprimierung gibt, sollten Sie die Ergebnisse zunächst individuell prüfen und bei Seiten, die auf qualitativ hochwertige Bilder setzen, darauf verzichten. Beispielweise sollten im Shop eines Herstellers für Kameras natürlich die Beispielbilder, die mit der Kamera erstellt wurden, keinen Qualitätsverlust durch die Komprimierungsverfahren erleiden und damit einem wichtigen Verkaufsargument entgegen stehen.

Online-Anbieter für die Verkleinerung der Bilddateien durch entsprechende Verfahren

Lokale Software

4) Grafiken und Icons zusammenfassen / Spriting

Icons, die sich wiederholen bzw. an vielen Stellen einer Seite eingesetzt werden, können in sog. Sprites zusammengefasst werden. Das CSS-Spriting ist eine in den letzten Jahren zunehmend verbreitete Möglichkeit, die parallelen Anfragen (HTTP-Request) auf den Webserver zu verringern und anstelle von vielen Kleinen, nur eine große Datei zu laden. Übermittelt man zusätzlich noch einen passenden Caching-Wert an den anfordernden Browser, so kann sich dieses Verfahren durchaus gerade für Grafiken lohnen, die sich auf einer Webseite nur selten ändern.

Spriting ist im Regelfall nicht automatisiert auf einer Webseite einsetzbar, da neben der vergleichsweise noch einfachen Zusammenfassung von Icons in eine Datei die Anpassung der jeweils betroffenen Stellen im Quelltext/CSS eine Herausforderung darstellt.
Über Erfahrungen von Anwendern entsprechender Tools oder Software-Empfehlungen freuen wir uns natürlich.

Im zweiten Teil gehen wir auf Caching, die Kompression mittels GZIP/DEFLATE und einige weitere Empfehlungen ein. Auch werden wir ein paar Tools und Plugins nennen, über die Sie Ihre eigene Webseite testen können.

Schlagworte:
von Dietmar Veröffentlicht in Allgemein

“Die Durchschnittserwartung der Ladezeit einer Webseite liegt bei etwa 4 Sekunden, alle Werte darüber werden von Besuchern als unangenehm empfunden und führen vermehrt dazu, dass diese Ihre Webseite wieder verlassen.”
So oder so ähnlich würde wohl ein mehr oder weniger einheitlicher Konsens diverser Umfragen unterschiedlichster Magazine und Experten lauten.

Die Empfehlungen im Internet und Statistiken von Umfragen variieren stark, so dass manchmal auch von 10 Sekunden, ein anderes mal von 2 Sekunden gesprochen wird. Dies ist sicherlich rein subjektiv und abhängig vom Empfinden des Einzelnen. Dass die Ladezeit aber ein wichtiger Faktor für erfolgreiche Auftritte im World Wide Web ist, ist nicht umstritten; hier sind sich die “Experten” mittlerweile einig.

Webseiten werden umfangreicher, die Ladezeit nimmt zu.

Betrachtet man den mobilen Sektor wird dieser Faktor auch immer mehr Gewicht erlangen. Die Bandbreiten sind dort noch einmal geringer als per DSL, Kabel o.ä. am Rechner zu Hause. Aber auch zu Hause kann man Glück haben und kann im Netz mit einer Geschwindigkeit von mehreren MB pro Sekunde oder aber auch nur von unter Einem surfen. Je nach Standort und Ausbau der Leitungen.

Um die Ladezeiten zu verbessern gibt es unterschiedliche Ansätze und Kombinationsmöglichkeiten. Das Thema wird in Fachmagazinen und von Experten immer wieder “ausgeschlachtet” und man kann unzählige Beiträge dazu finden. Das Problem dabei ist, dass viele Tipps nicht so umgesetzt werden können, wie sie empfohlen werden oder man selbst einfach zu wenig Wissen oder Erfahrung hat, diese auch so zu realisieren, dass nicht etwa das Gegenteil bewirkt wird.

Wir möchten Ihnen daher ein paar einfache und grundlegende Tipps geben, die Sie berücksichtigen können und die einen von vielen Schritten für die Verbesserung der Ladezeit Ihrer Webseite darstellen.

5 Tipps für eine schnellere Startseite:

  1. Stellen Sie in Ihrem Kundenmenü bei der PHP-Version die “LIGHT”-Variante ein. Diese beinhaltet weniger PHP-Module die beim Start von PHP durch den Aufruf Ihrer Webseiten auf dem Server geladen werden müssen.
    Bitte testen Sie aber die Funktionen der Webseite, um sicherzustellen, dass nicht durch die abgespeckte Version eine wichtige Funktion nicht mehr korrekt ausgeführt werden kann.
    Als Nutzer eines Managed- oder ResellerDedicated-Servers besteht auch die Option, FastCGI einzustellen.
  2. Verzichten Sie soweit möglich auf Erweiterungen für Ihren Shop, CMS, Forum oder Blog und deinstallieren Sie nicht mehr eingesetzte Plugins. Erstellen Sie sicherheitshalber vor einem Löschvorgang bitte ein Backup :)
    Viele Erweiterungen bringen, ebenso wie Templates für das Design und die Funktionen eigene CSS- und/oder Javascript-Dateien mit, die dann zusätzlich bei jedem Aufruf der Webseite geladen werden müssen. Das verzögert den Aufbau der Seite, denn die Anzahl der Dateien, die ein Browser gleichzeitig laden kann ist begrenzt und darüber hinausgehende zusätzliche Dateien werden immer erst anschließend geladen.
  3. Verzichten Sie auf die Einbindung vieler “externer Ressourcen”. Dazu zählen beispielsweise die diversen SocialMedia-Tools, externe Chat- und Supportboxen, Statistiksoftware etc.
    Bei jeder Fremdeinbindung muss der Browser eine Anfrage an den fremden Server schicken und auf Antwort und Übermittlung der Daten warten. Sind die Server oder Leitungen dort überlastet oder gibt es Probleme bei der Übertragung so kann sich auch dann der Aufbau Ihrer Seite verzögern.
  4. Setzen Sie nach Möglichkeit nur wenig Flash und Videos ein und lassen Sie diese nicht automatisch beim Aufruf starten. Dadurch wird verhindert, dass der Browser Teile des Videos schon laden und lokal cachen muss, damit es direkt abgespielt werden kann, noch bevor die Seite aufgebaut wurde.
  5. Prüfen Sie die Verwendung Ihrer Bilder und deren Auflösung. Haben Sie ein großes Bild, das für die Darstellung auf der Seite automatisch verkleinert wird? Dann verkleinern Sie das Bild lokal und laden es direkt in der passenden Größe hoch.

Der erste Eindruck zählt. Auch bei einer Webseite. Ist die Startseite schnell geladen, können weitere Seiten etwas langsamer sein und Sie dort mehr Inhalt zur Verfügung stellen. Die wichtigsten Punkte sollten auf der Startseite zu finden sein, zugleich soll sie jedoch nicht überladen wirken.

Abschließend möchten wir Ihnen noch ein paar Zahlen an die Hand geben:

Die Durchschnittsgröße von Webseiten legte in den vergangenen Jahren permanent zu. Ende 2010 lag diese nach einer Analyse des HTTP Archive (http://httparchive.org/) um die 720 Kilobyte, 2011 bei über 950 Kilobyte und für dieses Jahr liegen wir bereits bei über 1 MB. Hauptgrund dafür dürfte die ständig steigende Nutzung von JavaScript-Code sein und die Tendenz, gerade bei Shops auf hochauflösendere Produktbilder zu setzen.

Bildquelle: http://httparchive.org/trends.php

Absichtlich wurde in diesem Beitrag nicht auf Spriting von Bildern, Minifying von CSS, Caching, Lazy Loading u.ä. eingegangen, um das Thema und den Einstieg möglichst einfach zu halten und nicht mit Fachbegriffen um uns zu werfen ;)

Sollte der Bedarf vorhanden sein, können wir das gerne in einem anderen Blogeintrag etwas technischer ausführen und freuen uns natürlich über Kommentare.

Schlagworte:,
von Sara Veröffentlicht in Allgemein

SharedHosting ist an sich eine feine Sache: Zwar teil man sich Ressourcen mit anderen Anwendern, dafür erhält man jedoch sehr umfangreiche Leistungen zu gemessen daran günstigen Preisen. Gerade bei lasthungrigen Anwendungen bieten die üblichen Angebote im SharedHosting-Bereich jedoch oft nicht ausreichend Performance, um die gestellten Anforderungen vollständig erfüllen zu können.

Für Anwender mit hohen Ansprüchen ist das eine unbefriedigende Situation, für die wir mit unserem “ManagedHosting Pro” Angebot eine Lösung bieten möchten. Das Produkt wurde mit dem Gedanken an Entwickler, Webapplikationen, professionelle Anwender und Unternehmen konzipiert und bietet – neben vielen weiteren interessanten Möglichkeiten – auch konfigurierbare Performancestufen an. Diese können jederzeit (über Nacht) erhöht bzw. zum Ende der (in der Regel monatlichen) Laufzeit auch wieder genauso einfach reduziert werden. Damit lässt sich die Performance an steigenden (oder sinkenden) Bedarf anpassen.

Bei einem Tarifpreis von ab günstigen 9,95 €* kann die Leistungsfähigkeit des Hostingtarifs so Stück für Stück mit den eigenen Anforderungen “mitwachsen” und es fallen erst dann die Kosten für entsprechende Mehrleistungen an, wenn sie auch benötigt werden.

Damit bei steigenden Anforderungen der Wechsel auf zwar sehr leistungsfähige aber auch mit höheren Kosten verbundene dedizierte Serverhardware noch länger herausgezögert oder eventuell sogar vermieden werden kann, haben wir unser durchaus als Highend-Produkt zu bezeichnendes Hostingangebot “ManagedHosting Pro” nun m eine zusätzliche, siebte Performancestufe erweitert.

Diese zusätzliche Performancestufe mit dem Namen “7-Sterne-Performance” stellt dem Kunden rechnerisch einen “eigenen”, d.h. nicht mit anderen Kunden zu teilenden, Prozessorkern einer aktuellen Intel Xeon Server-CPU zur Verfügung (“1 Kunde/CPU-Kern”).

Abhängig von der gewählten Konfiguration stehen dem Anwender damit bis zu 100 GB Webspace, 100 GB Mailspace, eine Trafficflatrate und die 7-Sterne-Performance mit “1 Kunde/CPU-Kern” für gemessen an den Gesamtleistungen preiswerte 67,95 €* zur Verfügung. Im Preis enthalten sind die mehrfach kostenfreie Nutzung eines dedizierten Servers bei Überlastungen (“Überlastungsschutz”), ein in den Server eingebauter SSD-Cache für schnellere Dateizugriffe, ein bereitstehender Ersatzserver bei Hardwaredefekten, SSH, Ruby on Rails, die Nutzung des Speicherplatzes mit unserer LiveDisk(R), welche mittels WebDAV-Zugang auf den Webspace zur Nutzung als Onlinefestplatte bietet, und vieles, vieles mehr. Alle Produktdetails finden Sie hier.

Selbstverständlich können Sie unseren ManagedServer Pro Tarif ebenso wie die anderen Hostingangebote ohne Risiko testen. Denn dank einer “60 Tage Geld zurück” Garantie, die sowohl für Neukunden als auch nach Tarifwechseln von Kunden gültig ist, erhalten Sie bei Nichtgefallen innerhalb der ersten 60 Tage den bereits gezahlten Tarifpreis erstattet.

Haben wir mit dem ManagedHosting Pro Tarif ein für Sie interessantes Angebot geschaffen? Dann hoffen wir, dass er Ihre Erwartungen vollständig erfüllen wird und freuen uns über Feedback. Gerne auch in unserem Kundenforum. Bei Fragen steht Ihnen zudem unser kostenfreier Kundenservice natürlich gerne zur Verfügung. Alle Kontaktmöglichkeiten, wie z.B. unsere 0800-Rufnummer, finden Sie hier (Deutschland) bzw. dort (Österreich).

*) Monatlicher Tarifpreis; zzgl. 9,95 € Einrichtungsgebühr. Alle Preise inkl. gesetzliche Mehrwertsteuer. 

Intel und Intel Xeon sind Handelsmarken und/oder eingetragene Markenzeichen der Tochtergesellschaften in den USA und anderen Ländern.

von Sara Veröffentlicht in Allgemein

Für Kunden mit einem dedizierten Server haben wir die bereits angebotenen Statistiken und Graphen im Kundenmenü um eine neue Information erweitert: Den “Systemlastindex”. Dieser ist ein guter Indikator für die Serverauslastung und gibt Auskunft darüber, ob das System tendentiell kaum etwas zu tun hat oder sehr stark belastet ist. Eine vollständige Auslastung des Servers entspricht dem Systemlastindex 1.Der Höchstwert ist jedoch 5, da mehrere gleichzeitige Prozesse zu einer solchen Anzeige führen können (wie mir die Technik erklärt hat).

Der Index basiert auf dem Unix-Load-Wert geteilt durch die Anzahl der logischen CPUs (d.h. der CPU-Kerne + Hyperthreading).

Das sieht dann so aus:

Systemlastindex

Der Graph kann je nach Wunsch dynamisch skalieren (um kleine Ausschläge besser erkennen zu können) oder sich statisch an einer festen Achse orientieren. Die Neuerung gilt sowohl für bestehende Verträge als auch (natürlich) für neu bestellte dedizierte Server.