__ __ __ .-----.--.--.----.| |.--.--.--| |.-----.--| | .-----.----.-----. | -__|_ _| __|| || | | _ || -__| _ |__| _ | _| _ | |_____|__.__|____||__||_____|_____||_____|_____|__|_____|__| |___ | by l0om - member of excluded-team |_____| In Sachen Server-Stunts Nr.1: Webserver-Stunt 0x0100 Der Server-Stunt 0x0200 The Others 0x0201 TUX 0x0202 light http 0x0203 LiteSpeed 2.0 0x0204 not-tested-from-me-but-existing 0x0300 Benchmarks 0x0301 Non-KeepAlive 0x0302 KeepAlive 0x0303 PHP-test 0x0400 Getting things moving 0x0500 "Ende gut alles gut" oder "Schall und Rauch"? 0x0501 Seitenaufbaugeschwindigkeit 0x0502 Serverauslastung 0x0503 Schlusswort 0x0600 Greetings 0x01 Der Server-Stunt Der Apache Webserver glaenzt durch sein modulares Design in Sachen Flexibilitaet. Modulares Design bedeutet, dass die Funktionalitaeten des Servers von den geladenen Modulen stammen. jede Webanfrage wird durch Modul fuer Modul geschoben und so manches fuehrt irgendwelche Aktionen aus. "mod_access.c" bietet zum Beispiel die bekannten "Allow", "Deny" und "Order" Regeln welche man in der Apache Konfigurationsdatei finden kann. Kommt also eine Anfrage auf ".htaccess" gibt "mod_access.c" ein Verbot zurueck, denn in der Apache-Konfigurationsdatei ist zu finden, dass alle Dateien die mit ".ht" beginnen nicht angesehen werden duerfen. Es gibt eine ungeheuere Fuelle von Modulen und die Funktionalitaeten die der Apache leiten kann, steigen und steigen. Falls der Apache-Webserver mit Blick auf DSO compiliert wurde, dann koennen die benoetigten Module bei Bedarf nachgeladen werden. Bei der 0815 Installation sind alle Module statisch in der Apache Binary (httpd) zu finden. Abgesehen von der modularen Glanzleistung ist der Apache-Webserver nicht umsonst der populaerste Webserver der im Web zu finden ist. Der Apache ist "Sicher" (oder er kann es sein), hat eine grosse Nutzergemeinde die Hilfe leisten kann und ist relativ einfach zu konfigurieren. Absolut alles Materielle auf unserer Welt hat zumindest zwei Seiten und auch die Vorteile des Apache-Webservers haben ihre Nachteile. Da Apache so viel leisten kann, ist er nicht gerade der Schnellste. Es gibt zB. Webserver die im Bereich der statischen Seiten ein gutes Stueck schneller sind als der Apache. Diese wiederrum koennen jedoch nicht mit den Funktionen des Apache mithalten und koennen vielleicht nur statischen Inhalt darstellen. Wie waere es, wenn wir alle dynamischen Abfragen den Apache uebernehmen lassen und alle statischen Abfragen einen fuer diese Aufgaben besser geeigneten Webserver uebernehmen lassen? 0x02 The Others Es gibt ueberall Experten die die Haende ueber den Kopf zusammen schlagen, wenn man zugibt, einen profanen Webserver und nicht den geheiligten Apache zu verwenden. Um diesen Experten den Apache zu saekularisieren reicht oftmals schon ein einfacher Benchmark Vergleich, aber dazu spaeter mehr. 0x0201 TUX: Ein Webserver der in Form eines Kernelpatches kommt und daher ist die Installation etwas gewoehnungsbeduerftig ist. Abgesehen von der originellen Idee ist TUX sehr schnell wenn es um statischen Inhalt geht; dynamischen kann er nicht darstellen. 0x0202 light http: Page: http://www.lighttpd.net "Security, speed, compliance, and flexibility--all of these describe LightTPD which is rapidly redefining efficiency of a webserver; as it is designed and optimized for high performance environments. With a small memory footprint compared to other web-servers, effective management of the cpu-load, and advanced feature set (FastCGI, CGI, Auth, Output-Compression, URL-Rewriting and many more) LightTPD is the perfect solution for every server that is suffering load problems. And best of all it's Open Source licensed under the revised BSD license." Ich bin persoenlich mit lighttpd zufrieden. Die Installation war simpel und die Konfiguration ist zwar auf den ersten Blick zweifelhaft, aber bei genauerem Hinsehen gut und uebersichtlich. Abgesehen davon gibt es eine gute Docu. 0x0203 LiteSpeed 2.0 Page: http://www.litespeedtech.com "LiteSpeed web server is an Apache interchangeable, full-featured high performance, secure HTTP server specifically engineered from the ground up with security and scalability in mind. [...] LiteSpeed Web Server has superb performance. Our measurements shows that it is more than 6 times faster than Apache, beating other lightweight content accelerators, such as thttpd, boa and TUX when serving static content, plus up to 50% increase in PHP performance than that of Apache's mod_php and more than doubled CGI/Fast CGI performance." Von diesem Webserver war ich mehr als nur positiv ueberrascht. Die Installation war unverschaemt einfach, da man nicht einmal kompilieren brauchte und der Webserver trotzdem einen Affenzahn drauf hat. Die Konfiguration des Servers ist einfach mittels HTTP ueber einen Extraport zu regeln. Diese ist uebrigens sehr komfortabel und jeder Punkt der Konfigurierbar ist wurde kleinkariert dokumentiert. Daher ist Feintuning fuer jedermann moeglich und Konfigurationsfile hacking faellt dadurch ganz weg. Der Lightspeed kann uebrigens auch dynamischen Inhalt wie PHP oder CGI´s darstellen. Diesen Server sollte man wirklich eine Changse geben! 0x0204 not-tested-from-me-but-existing: IIS 6.0, boa 0.94.X, Mathopd 1.5p3 0x0300 Benchmarks Die Benchmarks stammen von dritter aber sicherer Quelle. ich habe fuer Apache und fuer LiteSpeed mit den selben Konfigurationen fast die selben Ergebnisse erhalten. Die Hardware war halt nicht die selbe, aber wenn man meine erhaltenen Werte in Relation mit diesen setzt, sind die folgenden als stimmig anzusehen. Wahrscheinlich ist fuer viele ueberraschend wie schlecht der Apache abschneidet, aber man darf dabei nicht vergessen, dass der Apache aufgrund seiner hohen Funktionalitaet auch einen recht hohen Overhead hat. Ich denke jeder der schon mal mit Apache gearbeitet hat, weiss aber was er von ihm hat... 0x0301 Non-KeepAlive test: ab -n 100000 -c http://:/100.html Level: 100 ++++++++++++++++++++++++++++++++++++++++++++++ Apache 1.3.33: 3021 Apache 2.0.52: 2874 LSWS 2.0 Std.: 11232 TUX 3.2: 18601 Lighttpd: 10998 Aolserver 4.0.7: 4020 Boa 0.94.14: 9404 KeepAlive test: ab -n 100000 -c -k http://:/100.html Level: 100 ++++++++++++++++++++++++++++++++++++++++++++++ Apache 1.3.33: 5163 Apache 2.0.52: 4673 LSWS 2.0 Std.: 24576 TUX 3.2: 53304 Lighttpd: 17253 Aolserver 4.0.7: 7564 Boa 0.94.14: 17094 PHP-test: ab -n 10000 -c http://:/phpinfo.php Level: 100 ++++++++++++++++++++++++++++++++++++++++++++++ Apache 1.3.33: 418 Apache 2.0.52: 433 LSWS 2.0 Std.: 609 Lighttpd: 423 0x0400 Getting things moving Folgender Plan wurde realisiert: Mein Apache Webserver sollte nach wie vor fuer die Verarbeitung von PHP zur Verfuegung stehen. Alle nicht dynamischen Daten soll sich der Browser von einem dafuer eingerichteten Server holen. Ich entschied mich aus Sympathiegruenden fuer LiteSpeed 2.0 :) Wie bekommen wir den Apache zum weiterleiten? Mit "mod_rewrite" und folgenden Anweisungen in der httpd.conf: --8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<-- RewriteEngine on # RewriteLogLevel 5 # RewriteLog "/usr/local/apache/logs/rewrite.log" # *Log* nur zum debuggen: frisst viel performance... RewriteRule ^/pics/(.*[jpg|jpeg|gif])$ http://192.168.1.17/pics/$1 RewriteRule ^/data/(.*)$ http://192.168.1.17/data/$1 --8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<-- Wie der Leser schon vermutet, ist unser LiteSpeed Server unter der Adresse 192.168.1.17 zu erreichen. Auf diesem Server befinden sich in den Ordnern "pics" und "data" die gleichen Dateien wie auf dem Apache. Alle Anfragen auf Bilddateien im Ordner "pics" werden also nun mittels Redirect umgeleitet, auf einen dafuer besseren Server. Ähnliches gilt fuer "data", nur dass sich dort andere statische Daten befinden (moeglicherweise nur fuer Downloads, etc.). Der LiteSpeed Webserver laesst sich nun sehr gut fuer seine Aufgabe konfigurieren und tunen. Wir brauchen auf diesem zweiten Server zB. nicht mehr unbedingt Logging, was ziemlich viel Performance frisst. Es lohnt sich auch, bei seinen statischen Daten ueber den Komprimierungsgrad des Inhalts nachzudenken. Eine hohe Kompression lohnt naemlich nur bei etwas groesseren Dateien. Hier mal ein Ergebniss vom Tuningexperiment: [Vorher] Concurrency Level: 1 Time taken for tests: 83.418 seconds Complete requests: 10000 Failed requests: 0 Broken pipe errors: 0 Total transferred: 20280000 bytes HTML transferred: 17910000 bytes Requests per second: 119.88 [#/sec] (mean) Time per request: 8.34 [ms] (mean) Time per request: 8.34 [ms] (mean, across all concurrent requests) Transfer rate: 243.11 [Kbytes/sec] received [Nachher] Concurrency Level: 1 Time taken for tests: 49.612 seconds Complete requests: 10000 Failed requests: 0 Broken pipe errors: 0 Total transferred: 20280000 bytes HTML transferred: 17910000 bytes Requests per second: 201.56 [#/sec] (mean) Time per request: 4.96 [ms] (mean) Time per request: 4.96 [ms] (mean, across all concurrent requests) Transfer rate: 408.77 [Kbytes/sec] received Na, das ist doch schonmal was. Happy Tuning! 0x0500 "Ende gut alles gut" oder "Schall und Rauch"? Das System wurde spaeter von mir nicht mit "ab" getestet, weil "ab" dafuer nicht geeignet war. Der Grund ist, dass "ab" sich nur den Seitenquelltext zieht und nicht die verlinkten Bilder etc. Daher habe ich mittels "wget" die Seite komplett einige hundert male runtergeladen. 0x0501 Seitenaufbaugeschwindigkeit? Das war logischerweise abhaengig von dem Seiteninhalt. Bei einer Seite mit 5 Bildern (gif/jpeg) ist unser Webserversystem ca. 1 Sekunde schneller als das alte System. Das Ergebniss fand ich persoenlich nicht so berauschend und es ruehrte daher, dass bei einer Bildanfrage vom Browser, der Browser einen HTTP Redirect zu dem anderem Server bekam, sich mit dem Verbinden, und dort das Bild saugen musste. Das war ja von Anfang an klar, aber um wieviel schneller oder langsamer dieses neue System ist, liess sich nicht sicher vorraussagen. Abgesehen davon, kann man mittels TUX auch noch mal Geschwindigkeit rausholen (siehe Benchmarks). Ich denke aber nur die wenigsten haben Interesse ihren Kernel zu einem Webserver zu patchen :). Ich probierte dann mit der "RewriteRule" Option "[P]" und "mod_proxy" aus, das Redirect zu umschiffen, was auch funktionierte. Nur muss man sich auch hier klar machen, dass der Server nun eine zusaetzliche Verbindung aufbauen muss, um sich das Bild zu saugen. Die Bytes des Bildes werden durch den Webserver zu dem Browser transportiert. Der einzigste Vorteil der dabei erzielt werden konnte, war die Datenkompression auf eine andere lahme Buechse zu packen. Das ganze hatte auch den erwarteten Effekt: naemlich so gut wie keinen 8) 0x0502 Serverauslastung? Hier gab es eine Überraschung meinerseits. Mit dem oben genannten Szenario hatte das alte System Auslastungsspitzen von bis zu 11% CPU-Last. Bei unserer Variante bekam ich eine Hoechstlast von 2-3% CPU-Last; das ist doch mal zur Abwechslung was positives. Zuerst hatte ich bei unserem neuen System eine Auslastung jenseits von Gut und Boese und stellte anschliessend fest, dass der Bremsklotz das Logging von "mod_rewrite" war, welches ich dann auch abstellte. Zu erwaehnen ist noch, dass der zweite Server fuer den statischen Inhalt durchaus eine alte Kiste sein kann. 0x0503 Schlusswort Eine offensichtliche Regel der Logik besagt, dass eine Behauptung entweder wahr oder falsch ist. Wenn man nun Behauptet, dass dieses Konzept eine prima Loesung ist, soll dem Leser ueberlassen sein, was fuer diese Behauptung nun zutrifft. Wenn man den Gedanken weiterstrickt gelangt man zur Erkenntnis ("a priori" versteht sich ;] ), dass dieser Text- ob das Konzept gut oder schlecht ist- seinen Dienst getan hat. Denn selbst wenn gezeigt wurde, dass das Konzept schlecht ist, gibt es nun weniger Behauptungen die zu ueberpruefen sind und die Wahrscheinlichkeit ein gutes Konzept zu finden steigt. Damit ist Bewiesen das der Text von Nutzen ist, denn ein Beweis kann sich solange einer nennen, wie er eine Tatsache ist, die sich staendig verifizieren und nicht falsinieren laesst. Denkt mal drueber nach und ihr werdet mir alle fuer diesen Text noch lange dankbar sein :D Ich hoffe ihr wurdet gut unterhalten und lacht jetzt noch darueber mit was fuer Kram ich meine Zeit manchmal totschlage. 0x0600 Greetings Mister Theldens: For the good idea, tipps and other stuff All the guys from Excluded: Nice to know you all! Maximilian: For testing-servers and his full beer-storage Prof. J. Dealer: "Schiess dir´n Loch in den Sack und strib tanzend" detach: think of probability computation partner! ;) mattball, mika, molke, vy99, Dr.Dohmen, ole, commander-jansen and everybody who knows me! --http://www.excluded.org