FrOSCon 2006
25. Juni 2006
Axel Beckert
<abe@noone.org>
http://noone.org/abe/
Grob 80% aller Rechenleistung wird für 20% aller Funktionen gebraucht. Sowohl auf Webservern als auch bei Webbrowsern. Braucht man das wirklich?
Warum Webseiten bei jedem Aufruf neu generieren wenn sie doch eh immer wieder gleich aussehen? Warum die Benutzeroberfläche des Webbrowsers mit der gleichen Technik wie die Webseiten erstellen, wenn es fertige GUI-Bibliotheken gibt?
KISS steht ursprünglich für "Keep it simple, stupid" (dt.: "Halte es einfach, Dummerchen") und soll aus dem Apollo Projekt der NASA stammen, das KISS-Prinzip, etwas einfach und übersichtlich zu halten, hat sich aber in viele Ingenieursbereiche und vor allem auch im Computerbereich verbreitet.
In der Zwischenzeit haben sich immer mehr Interpretationen des Akronyms KISS angesammelt, die aber allesamt in die gleiche Richtung gehen:
(Quelle: engl. Wikipedia-Artikel "KISS principle")
KISS fand in der Computerwelt insbesondere beim Design von UNIX Verwendung und ist damit auch bei vielen freien Betriebssystemen präsent, z.B. bei Linux und den ganzen BSD-Varianten.
Vor allem auf der Kommandozeile findet sich KISS wieder: Viele kleine Programme (z.B. sed, awk, grep, find, sort, uniq, etc.), die alleine nur eine Aufgabe erledigen, diese aber gut, schnell und zuverlässig — erst das Zusammenspiel mehrere dieser kleinen Tools macht die Kommandozeile unix-artiger Systeme so mächtig.
Und da die meisten dieser Programme wirklich nur eine Aufgabe machen, sind sie klein, kompakt, übersichtlich und schnell. KISS eben.
Und wenn Software nach dem KISS-Prinzip gestaltet wurde, läuft sie im Normalfall auch auf älterer, nicht mehr ganz so performanter Hardware ganz gut. Entsprechend kann man mit einfach gestalteter Software auch im Web schon sehr viel erreichen.
Es gibt in der Zwischenzeit einige Distributionen, die speziell auf alte Hardware zugeschnitten sind — oft mit Anleihen bei Embedded-Systemen. Meist sind diese Distributionen auf einen bestimmten Zweck zugeschnitten und kommen nur mit einer entsprechend eingeschränkten Paketauswahl daher. Beispiele:
Desktop Light (DeLi) Linux ist als Desktop-System mit Kernel 2.2 primär für 486er und Pentium 1 gedacht und kommt mit einer Sammlung von ressourcenschonenden Anwendungen, darunter auch einige kompakte Webbrowser, aber auch kompakte Webserver. Trotz mitgelieferter Webserver ist es mehr als Entwicklungssystem für Webseiten und -anwendungen gedacht als für den produktiven Server-Einsatz. 90 MB ISO, passt auch auf 100-MB-Zip-Disketten.
Damn Small Linux (DSL) ist eine vielseitige, auf den Desktop ausgerichtete und auf Debian basierende Live-Distribution, die ab 486DX mit 16 MB RAM läuft, in eine 128-MB-RAM-Disk geladen werden kann und bei einer Festplatten-Installation in ein Debian umgewandelt werden kann.
fli4l, ist ein Ein-Disketten-Router, der über das Netz weitere Pakete nachladen kann, u.a. auch um ihn um Webserver-Funktionalitäten zu erweitern.
Es gibt aber auch Allround-Distributionen bzw. -Ports-Sammlungen, die alleine schon aufgrund ihrer Auswahl an Paketen bzw. Ports genügend Alternativen zu den gängigen, aber tlw. ressourcenfressenden Anwendungen und Serverdiensten mitbringen, allen voran Debian mit über 14'000 Paketen in der aktuelle Distribution, aber auch Gentoo und die FreeBSD Ports Collection bieten viel Auswahl, auch bei Webservern, Webbrowsern und anderen Tools rund ums Web.
Apache alleine braucht nicht viel Ressourcen und ist bei passender Konfiguration auch für alte, etwas schwächere oder gut ausgelastete Rechner ein Überlegung wert.
"Ressourcenschweine" sind dagegen dynamische Webseiten mit mod_perl, Embperl, PHP, JSP, o.ä. — nicht nur, weil sie bei jedem Aufruf ausgeführt werden sondern vor allem, weil sie einmal geladene Module und Seiten im Speicher halten — und dies für jeden Apache-Kindprozeß.
Eine Möglichkeit ist, statische und dynamische Seiten von getrennten Prozessen ausliefern lassen:
Folge: Nicht alle gebrauchten sondern nur ein paar wenige Webserver-Prozesse haben hunderte von Perl-, JSP- oder PHP-Modulen und -Webseiten vorkompiliert im Speicher vorrätig. Und für statische Webseiten braucht es nur den Systemcall sendfile(2) zum Raussenden. Den Rest macht der Kernel.
Es gibt neben den "großen" Webservern wie Apache, Roxen und Co. auch viele, kleine Webserver, die zwar oft wenig Features haben, dafür aber auch wenig Ressourcen brauchen, sehr schnell sind und sich auch von einer großen Menge an Anfragen nicht beeindrucken lassen, so z.B. Boa, bozohttpd, dhttpd, fnord, mathopd, micro-httpd (per inetd), thttpd oder thy. Wenn, wie oft auf sehr alten Rechnern, geringer Speicherverbrauch wichtiger als Performance ist, nicht nur selten gebrauchte Daemons sondern auch den Webserver per inetd laufen lassen.
Was aber tun, wenn man statische Webseiten einheitlich gestalten will, aber nicht immer alle Änderungen am Design oder der Menüstruktur manuell nachpflegen möchte?
Es gibt zwei einfache Lösungen für dieses Problem:
CSS-basierte Webseiten bieten die Möglichkeit, das komplette Design auszutauschen ohne alle Dateien zu bearbeiten. Und Seiten ohne tief verschachtelte Tabellen machen Webs schlanker, übersichtlicher, leichter wartbar und einfacher zu vereinheitlichen. Und wenn das CSS in einer externen Datei liegt, muß es auch nur einmal vom Server geladen werden und ist dann im Cache.
Die andere Möglichkeit ist, Webseiten aus "Quellen" statisch zu generieren, wie man aus C-Code ausführbare Programme kompiliert.
Ein Tool bzw. genauer eine Tool-Sammlung, das speziell für diesen Zweck entwickelt wurde, ist die Website Meta Language, welche aus neun hintereinandergeschalteten Tools besteht, die jeweils als Filter fungieren und zusammen eine relativ mächtige und dennoch übersichtliche Makro-Sprache bieten.
Wenn man eher ein Blog statisch generieren möchte, dann ist eher Blosxom (oder evtl. auch eines der Derivate wie PyBlosxom) einen Blick wert.
Ansonsten bieten viele sog. Templating-Systeme die Möglichkeit,
Webseiten "offline" zu generieren (z.B. "embpexec.pl" bei Embperl und
"php" bei PHP).
Um für Eltern, Großeltern oder kleine Geschwister aus einem alten, auf den ersten Blick nicht mehr nutzbaren Rechner ein Surf-Terminal zu machen, braucht's nicht viel:
Eine geeignete Linux-Distribution oder ein BSD und einen passenden, sparsamen Webbrowser, z.B.
Letzte Änderung an den Quellen:
Letzte Generierung:
Generiert von
$Id$