Da es immer mehr dieser “USB-Gadgets” gibt, ist mir heute auch so ein Gerät in die Hände gefallen. :-) Mit dem ecobutton soll man seinen PC schneller in den Energiesparmodus versetzten.
1.) Terminal öffnen und den User (in diesem Beispiel – “lars”) das Recht geben, ohne Passwort den PC in den Ruhezustand zu versetzten…
Da ich vor einiger Zeit von “Apache2” zu “nginx” als Webserver umgestiegen bin, den “alten Indianer” jedoch in der Zwischenzeit noch auf einem anderen Port (127.0.0.1:8080) aktiv hatte, war es nun an der Zeit diesen abzuschalten.
Jeder Dienst besitzt ein Start-/Stop-Skript im Verzeichnis /etc/init.d diese werden dann den verschiedenen Runleveln zugeordnet.
/etc/rc0.d – Während das System herunterfährt /etc/rcS.d – Während des Bootens ausführen /etc/rc1.d – Arbeiten als einzelner Benutzer /etc/rc2.d – Mehrbenutzerbetrieb inkl. Netzwerk /etc/rc3.d bis /etc/rc5.d – Nicht genutzt /etc/rc6.d – Während das System neu startet
Der Standard Runlevel von Debian / Ubuntu ist 2. Um diese Zuordnungen zu verstehen, zeige ich einfach ein Beispiel:
Wie man sieht handelt es sich hierbei um einen Symbolischer-Link welcher auf ein Start-/Stop-Skript zeigt. Um diese Zuordnung zu ändern gibt es den Befehl “update-rc.d”
update-rc.d apache2 defaults
Defaults bedeutet, dass Apache in den Runleveln 2-5 gestartet und in allen anderen beendet wird. In meinem Fall wollte ich den Dienst ausschauten und daher die Links entfernen, dies hab ich mittels diesem Befehl gemacht.
update-rc.d -f apache2 remove
Die Reihenfolge, vor/nach welchen anderen Scripts ein Dienst starten soll, wird über folgende Einstellungen geregelt.
Möchte man Apache z.B so einrichten, dass er nur in Runlevel 4 und 5 und nach allen anderen Diensten gestartet wird (99) , benutzt man folgende Zeile:
Die Zeile hat folgende Bedeutung: Füge Startlinks (die mit “S99…” beginnen) in /etc/rc4.d und /etc/rc5.d ein, füge außerdem Stoplinks (die mit “K01…” beginnen) in den anderen rc.xd-Verzeichnissen ein. Apache wird also bei Runlevel-Wechseln zuletzt gestartet und zuerst wieder beendet.
Alternativ gibt es ein Front-End, welches dies ebenfalls erledigen kann, dieses muss in den meisten Fällen jedoch erst-einmal installiert werden.
aptitude install sysv-rc-conf
Mit dem Befehl “sysv-rc-conf” kannst du nun sehr bequem Dienst ein-/ und ausschalten. (dies hat natürlich keinen Einfluss auf die momentan laufenden Prozesse, dieser musst du z.B. mit “/etc/init.d/apache2 stop” oder “pkill apache2” beenden)
Heute zeige ich, wie du dir deinen eigenen Webserver (Nginx) als .deb-Paket bauen und installieren kannst… :-) In einem vorherigen Beitrag hatte ich bereits beschrieben, wie du PHP5-fpm mit Nginx installieren kannst. Da ich folgenden Fehler bei dem Update auf Version 0.9.1 bekommen habe ->
Can't locate nginx.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.
<- wurde das deb-Paket kurzerhand neu-gebaut und zwar ohne Perl-Unterstützung. :-)
1.) Root werden und einiges ggf. nachinstallieren + die Quellen (deb-src) herunterladen
Ich habe einige Module deaktiviert welche ich nicht benötige, SSL-Verschlüsselung + IPv6 + … aktiviert und unter anderem Optimierungen für meine CPU aktiviert. Unter folgendem Link, findest du alle Module, welche standardmäßig bei “nginx” mitgeliefert werden:
In dieser Datei muss man ggf. noch Abhängigkeiten ergänzen oder entfernen. In meinem Fall habe ich die perl-lib entfernt, da ich dies auch aus der zu-vorigen Konfiguration entfernt hatte.
4.) Ggf. die Konfiguration ändern bzw. deine eigene übernehmen (debian/conf/)
Dafür änderst du einfach die Dateien unter “debian/conf/” und sobald du das fertige Paket installierst, wird deine Konfiguration übernommen, dies kann auch sehr hilfreich sein, wenn du das selbe Programm mit den selben oder ähnlichen Konfiguration auf verschiedenen Computern installierst.
Wer komplett auf nginx als Webserver umsteigen will kann dies auch sehr einfach bewerkstelligen. Ich persönlich nutzte diese Methode und es laufen mehrere WordPress-Webseiten, e107, DokuWiki u.s.w. tadellos mit diesem System.
Als erstes müssen wir unsere sources.list ein wenig erweitern… um php5-fpm direkt mit dem Projektmanager installieren zu können, wie dies Funktioniert habe ich bereits in einem anderen Beitrag beschreiben: php-5-FPM
Danach installieren wir nginx (Webserver) + PHP, wenn du noch apache2 oder einen anderen Webserver, welcher auf Port 80 lauscht installiert hast, musst du diesen nun deinstallieren bzw. erst einmal stoppen und ggf. einige libraries nachinstallieren, falls du Ubuntu und nicht Debian nutzt.
Nun kommen wir zur Konfiguration, ich poste hier einfach mal meine komplette Konfig, daher sollte diese ohne Probleme lauffähig sein, wenn du die aktuelle Version installiert hast.
so nun richten wir unsere erste Webseite ein… (domain.de muss in den nachfolgenden Howto durch deine eigene Domain ersetzt werden und natürlich für jede neue Werbepräsenz eine neue Datei angelegt werden.
nun müssen wir die Webseite nur noch aktivieren, indem wir die soeben erstellte Datei verlinken.
cd /etc/nginx/sites-enabled/
ln -s ../sites-available/domain.de.conf .
nginx -t
/etc/init.d/nginx restart
Und schon läuft unser neuer Webserver. :-) Um die neuste Version von Nginx auf Debian/Ubuntu zu installieren kann man ggf. noch folgende Quellen in die “sources.list” eintragen.
Nun leben wir für eine Webseite eine PHP-Konfiguration an:
vim /etc/php5/fpm/pools/domain.conf
[domain]
; one Port for one Website
listen = 127.0.0.1:11000
; uid/gid
user = domain_user
group = domain_group
; logging
request_slowlog_timeout = 5s
slowlog = /var/log/slowlog-domain.log
; Choose how the process manager will control the number of child processes.
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
; Pass environment variables
env[TMP] = /var/www/www.domain.de/phptmp
env[TMPDIR] = /var/www/www.domain.de/phptmp
env[TEMP] = /var/www/www.domain.de/phptmp
; inculde defaults
include = /etc/php5/fpm/common.conf
; host-specific php ini settings here
;php_admin_value[open_basedir] =
Jetzt läuft der PHP-fpm Prozess mit den Rechten des jeweiligen Users und mit eigenem Tmp-Verzeichnis, wer will kann php-fpm sogar in einer chroot-Umgebung ausführen lassen :-)
Dustin Kirkland, Core Developer vom Ubuntu Server hat etwas interessantes in seinem Blog geschrieben. Und zwar wie man sich über beendete Befehle in der Shell benachrichtigen lassen kann. Falls ein “make” oder “grep” … mal wieder etwas länger dauert, kann man beruhigt weiterarbeiten und wird per NotifyOSD darüber benachrichtigt, wenn der Befehl beendet wurde.
Dazu musst du als erstes folgende Datei editieren:
vim ~/.bashrc
alias alert_helper='history|tail -n1|sed -e "s/^\s*[0-9]\+\s*//" -e "s/;\s*alert$//"'
alias alert='notify-send -i /usr/share/icons/gnome/32x32/apps/gnome-terminal.png "[$?] $(alert_helper)"'
sudo apt-get install libnotify-bin
source ~/.bashrc
Und schon kannst du es testen, einfach den “alert”-Befehl inter deinen Befehl schrieben, fertig…
So langsam möchte ich auf die Fragen, welche bisher aufgetaucht sein könnten eingehen und mit der Beschleunigung der Webseite anfangen, daher starten wir mit der Komprimierung.
Alle neuen Browser (ab IE6) unterstützen komprimierte Dateien, man kann sich dies so ähnlich vorstellen, wie in dem diesem Proxy-Beispiel, wo die Dateien serverseitig komprimiert werden und vom Client, in unserm Fall nun der Browser wieder dekomprimiert werden. Aber dazu kommen wir gleich. Das Problem ist, dass Bilder bereits komprimiert sind und falls diese im Nachhinein noch einmal passiert, diese sogar größer werden können als zuvor, daher versucht man diese bereits bei der Bereitstellung in der optimalen Dateigröße anzubieten, zudem sollte man vermeiden, dass zu viele kleine Dateien vom Server geladen werden müssen, da zu viele Verbindungen bzw. Anfragen sich auch seht negativ auf die Performance einer Webseite auswirken.
2.1) Bilder komprimieren
2.1.1) Bilder Sprites
Durch viele kleine Icons / Menü-Bildern kommen viele Serveranfragen zustande, welche man durch ein größeres Bild, welches dann wiederum mit css so bearbeitet werden kann, dass man bestimmte Bildabschnitte ansprechen kann, ersetzten könnte.
Es folgt noch ein Beispiel, um das Prinzip zu verstehen…
alte CSS-Regeln:
#header {background: url(bild1.jpg) top left repeat-x; height:80px;}
ul.menu li {background: url(bild2.jpg) top left repeat-x; height:15px;}
bild1.jpg und bild2.jpg sind jeweils 1px breit. Waf der folgenden Webseite → Sprite-Generator ← kann man diese beiden Dateien nun zu einer Sprite-Datei zusammenfassen und herunterladen bzw. auf Webserver hochladen.
Dieses Sprite-Bild wird nun für alle Elemente, die einen im Sprite enthaltenen Hintergrund haben eingefügt:
#header, ul.menu li {background-image:url(bg_sprite.png);}
Mithilfe der im Generator angegebenen Regeln, werden die alten CSS-Regeln ersetzen:
Dies fällt bei größeren Bildern mehr ins Gewicht, jedoch kann auch die Komprimierung von solchen Logos etc. schon einige hundert MB im Monat einsparen, zumal PNG in Gegensatz zu JPEG eine verlustfreie Neukomprimierung unterstützt.
Als alternative zu all dieses serverseitigen Möglichkeiten kannst du deiner Bilder natürlich auch mit einem Bildbearbeitungsprogramm (z.B. Paint.NET) öffnen und z.B. optimiert für Webseiten abspeichern.
2.2) JavaScript/CSS komprimieren
2.2.1) JavaScript/CSS komprimieren – serverseitig
Hier werde ich kurz zeigen wir du deine JS- und CSS-Dateien nicht nur komprimieren kannst, um die Ladegeschwindigkeit deiner Webseite zu verbessern, sondern auch noch optimierst, so dass diese schneller ausgeführt werden. Der CSS-Kompressions-Algorithmus verwendet zudem einen Satz von fein aufeinander abgestimmten reguläre Ausdrücke, um die CSS-Datei zu komprimieren.
[stextbox id=”info”]Bei mir hat das kombinieren von einigen JS- und CSS-Dateien negative Auswirkungen gehabt, so haben einige JS nicht mehr funktioniert, zudem sollte man bedenken, dass einige Dateien nicht auf jeder Webseite benötigt werden und daher auch ruhig später geladen werden können, sobald ein Besucher z.B. auf Kommentare klickt.[/stextbox]
Eine weitere Methode besteht darin, die Daten selber gar nicht zu verändern, sondern diese direkt und nach einer bestimmten Zeit neu von einem Server komprimieren zu lassen, diese Methode hat daher auch wieder nachteiligen Einfluss auf die Ladegeschwindigkeit, da ein weitere Request, DNS-Lookup usw. hinzukommt. Jedoch kann man an diesen Online-Dienst auch mehrere CSS- bzw. JS-Dateien gleichzeitig übergeben. Ob dies wirklich die Performance steigern kann müsste man im Einzellfall ausprobieren.
Serverseitige Komprimierung und somit eine Reduzierung der zu Übertragungen Datenmengen von 40 – 70 % sind hier zu erreichen, zudem kannst du mithilfe der folgenden Konfigurationen gleich mehrere Webseiten, welche auf dem selben Server laufen optimieren.
ohne gzip-Kompression:
mit gzip-Kompression:
Aktiviere mod_deflate (gzip) – serverseitig
Diese Art der Komprimierung macht natürlich nur bei Dateien Sinn, welche auch komprimiert werden können z.B. HTML, CSS oder Javascript …
a2enmod deflate
… dieser Befehl kann unter anderen Distributionen anders aussehen z.B.: BSD
Mithilfe von gzip (DeflateCompressionLevel) kann man verschneide Kompressions-Level einstellen, wobei 1 die schnellsten Komprimierung (weniger Kompression) und 9 die langsamste Komprimierung (beste Kompression) ist. Die Standard-Kompressions-Level ist 6. da eine zu hohe Kompression auf Kosten der der Systemleistung geht, ggf. kann man diesen Wert anpassen, wenn man noch genügend Ressourcen frei hat.
Nun müssen wir unsern Webserver neu-starten, um die Konfiguration zu übernehmen.
Wer noch apache und nicht apache2 verwendet sollte “mod_gzip” anstelle von “deflate” ansehen, jedoch werde ich nicht weiter auf die veraltete Apache-Version eingehen, wenn noch jemand den alten “Apache Web-Server” einsetzt, soll man ggf. ein Update auf apache2 durchführen…
“Nur unter Apache 1.3 ist “mod_gzip” effektiver ab “Apache 2.x” sollte man “mod_deflate” verwenden.”
Es gibt auch noch die Möglichkeit Dateien serverseitig im Vorhinein zu komprimieren und in einer .htaccess anzugeben, welche Dateien bzw. Dateiendungen vom Browser wieder dekomprimiert werden müssen. Ich selber habe auch eine Mischung aus den verschienden Komprimierungsverfahren gewählt, so habe ich sehr große JS-Dateien im Vorhinein folgendermaßen komprimiert, so dass der Server dies nicht jedes mal machen muss, zudem hat dieses Verfahren den großen Vorteil, dass man die negative Auswirkung des hohen Komprimierungslevel, auf die Systemauslastung umgeht.
Der Artikel beschreibt, wie man seine Webseite bzw. seinen Server analysiert und optimiert um Performance zu gewinnen, Ladezeit zu reduzierten bzw. Traffic einzusparen. Man kann einiges an Performance gewinnen, indem man z.B. Bilder im richtigen Format abspeichert bzw. komprimiert, CSS- / JS-Dateien kombiniert und ebenfalls komprimiert oder auch bestimmt Daten vorkomprimiert zur Verfügung stellt.
Abschließend möchte ich diesen Thema noch einmal kurz zusammenfassen, so dass man ggf. selber weitere Möglichkeiten erkennt, die Ladegeschwindigkeit seiner Webseite zu verbessern, jedoch nicht auf die Technische Umsetzung eingehen.
Kenne deinen Feind !!!
80 bis 90% der schlechten Performance liegt an der Webseite selber und nicht auf der Serverseite, solange nur wenig Besucher auf deiner Webseite sind, braucht man sich eigentlich um einen Revere-Proxy oder eine alternative zu Apache keine oder zumindest nur wenig Gedanken machen, da die Performance erst mit steigender Besucherzahl einbricht. Jedoch sollte man in jedem Fall die gzip-Komprimierung und den Browser-Cache nutzen.
Externe Dateien (Bilder, JS, CSS, Videos…)
Jeder Aufruf einer Datei kostet Performance und Bandbreite, daher sollte man im allgemeinen weniger Requests produzieren, indem man z.B. JS- bzw. CSS-Dateien kombiniert. Dieser negative Einwirkung steigt dramatisch bei externen Dateien von andern Servern und besonders dann, wenn dieser gerade mal nicht erreichbar ist.
Scripte
Immer wenn eine Browser eine Webseite abruft und im HTML-Code ein Script finde, wird das weitere laden der Webseite eingestellt und erst-einmal die JavaScript Engine damit beansprucht, diesen zu interpretieren. Daher sollte man diese Dateien erst am Ende der Webseite laden lassen, so dass der User die Webseite früher sehen kann, auch wenn z.B. die Animation des Menüs erst nach nachgeladen werden muss. Mit diesem Ansatz, erscheint es nur Sinnvoll CSS-Daten am Anfang laden zu lassen, so dass sich die Webseite dem User direkt im korrektem Layout präsentiert.
Bilder
Ein weites großer Bereich sind Bilder, dabei muss man jedoch ein gutes Mittelmaß an Text und Bildern finden, da die User zwar Bilder immer schön finden.. Logo, Hintergrundbild u.s.w. jedoch macht es nur wenig Sinn seine selbst jeder kleine Datei zu optimieren, wenn man oben über der Webseite ein 300 KB großes Bild eingefügt hat. Wie bereit im Artikel beschrieben gibt es jedoch zahlreiche Methoden (PNG- und JPEG-Dateien) diese zu optimieren.
Yahoo hat zudem eine sehr umfassende Liste von weiteren Regeln zusammengestellt, welche man beachten sollte.
Mit “nagstamon” hast du deinen Monitoring-Server (Nagios) immer in Sicht und bemerkst so vielleicht, dass ein Server ein Problem hat, bevor es zu spät ist.
Habe auf meinem Laptop folge Software nachinstalliert
sudo aptitude install powertop laptop-mode-tools
Stromverbrach + hilfreiche Tricks anschauen:
sudo powertop
Und mit ein wenig Konfigurationsarbeit, kannst du die Tips von powertop, in dein System integrieren:
z.B. in /etc/laptop-mode/batt-start/. Man kann auch bestimmt Dienste z.B. “preload” welche einerseits Ihren nutzen haben, jedoch anderseits auch CPU-Last verursachen und somit Strom verbrauchen stopen und wieder starten, sobald der Netzstecker wieder eingesteckt wird.
Im Blog webupd8.org habe ich ein Shell-Skript gefunden, um auf Ubuntu 10.04 einige Einstellungen und Programme zu installieren bzw. zu konfigurieren. Habe das Menü zu “dialog” migriert. Falls jemand noch eine Ideen hat, was man im Skript ergänzen oder verbessern kann, wäre ich für jeden Hinweis dankbar.
[stextbox id=”warning” caption=”Warnung”]Da ich nicht viel Zeit in das Skript gesteckt habe, sind ggf. noch etliche Fehler darin enthalten und man sollte dies als Alpha-Version ansehen. ;-)[/stextbox]