Ich wollte hier mal einen Thread zu dem Thema aufmachen.
Die Suche übergab keine Übereinstimmungen.
Ich hab das jetzt gerade machen müssen, und wollte kurz meine Erfahrungen wiedergeben und vielleicht Eure Erfahrungen hören. Hierbei ging es mir auf einen VPS (Virtual Privat Server) mit root-Zugang die nötigen Einstellungen zu machen, dass mindestens 300 Leute gleichzeitig online sein können, ohne das es zu Performance-Einbrüchen kommt. 150 gleichzeitig konnten bisher getestet werden, und es hat 100 %ig funktioniert.
System: Apache2 und MySQL 4.1.13
Apache leider default auf prefork kompeliert -> worker wäre besser.
/etc/apache2/server-tuning.conf:
StartServers 10
MinSpareServers 20
MaxSpareServers 40
ServerLimit 500
MaxClients 300
MaxRequestsPerChild 0
MaxKeepAliveRequests 300
/etc/apache2/httpd.conf:
HostnameLookups off
Das habe ich gemacht, damit der Server keinen DNS-Revers-Lookup mehr macht. Dadurch wird die Antwortzeit nach einem Timeout des Servers (default 15sec) drastisch gesenkt, der er eben nicht mehr auf die Antwort des DNS-Servers warten muss.
/etc/sysconfig/apache2
APACHE_MODULES
Da werden die Module für den Apache gelade.
Ich habe mod_perl entfernt, da es sehr groß ist und bei jedem Apache-Prozess unnötig Speicher frisst. Ich brauche perl nicht, so konnte ich das machen.
MySQL:
/etc/my.cnf
Im Verzeichnis /usr/share/mysql/ befinden sich Beispiele für verschieden große Datenbanken.
ich habe die Einstellungen aus der my-large.cnf genommen.
zusätzlich habe ich die max_connections auf 200 hochgesetzt, default ist 100.
Serveroptimierung für BG's
gepostet vor 17 Jahre, 11 Monate von open_dimension
gepostet vor 17 Jahre, 11 Monate von mifritscher
StartServers 10 <- ist noch ok
MinSpareServers 20 <- passt überhaupt nicht zum obigen Wert, der startet ja gleich 20 Processe. Immer 20 Processe offen zu halten hate ich für Speicherverschwendung
MaxSpareServers 40 <- auch bissle hoch, aber noch ok
ServerLimit 500 <- extrem hoch, ich glaube nicht dass dein Server 500 Prozesse abarbeiten kann
MaxClients 300 <- aha, 500 Prozesse, aber nur 300 Clients *g*
MaxRequestsPerChild 0 <- würde ich auf 1000 Requests oder so stellen, damit die Processe immer mal restartet werden, um Speicherlecks zu killen.
Gleichzeitig on != gleichzeitige Zurgiffe
Stelle dein keepalivetimeout auf nen wert wie 3 oder 5 Sekunden, dann dann bleiben nicht so viele Prozesse hängen und du brauchst nicht so viele.
Suche mal in deiner apache.conf nach ExtendedStatus und stells auf on.
Zusätzlich suchst du den Bereich mit SetHandler serverstatus, und stellst ihn so ein, dass du drauf zugreifen kannst. So bekommst du sehr genaue Infos über die Auslastung.
MinSpareServers 20 <- passt überhaupt nicht zum obigen Wert, der startet ja gleich 20 Processe. Immer 20 Processe offen zu halten hate ich für Speicherverschwendung
MaxSpareServers 40 <- auch bissle hoch, aber noch ok
ServerLimit 500 <- extrem hoch, ich glaube nicht dass dein Server 500 Prozesse abarbeiten kann
MaxClients 300 <- aha, 500 Prozesse, aber nur 300 Clients *g*
MaxRequestsPerChild 0 <- würde ich auf 1000 Requests oder so stellen, damit die Processe immer mal restartet werden, um Speicherlecks zu killen.
Gleichzeitig on != gleichzeitige Zurgiffe
Stelle dein keepalivetimeout auf nen wert wie 3 oder 5 Sekunden, dann dann bleiben nicht so viele Prozesse hängen und du brauchst nicht so viele.
Suche mal in deiner apache.conf nach ExtendedStatus und stells auf on.
Zusätzlich suchst du den Bereich mit SetHandler serverstatus, und stellst ihn so ein, dass du drauf zugreifen kannst. So bekommst du sehr genaue Infos über die Auslastung.
gepostet vor 17 Jahre, 11 Monate von neit
Ich würde mehr Mysql- als Apache-Connections erlauben. Hat sich zumindest bei unserer Software als vorteilhaft erwiesen. Andernfalls konnte es zu einer Warteschlange am Mysql kommen, die schlussendlich den ganzen Server zum erlahmen gebracht hat, obwohl eigentlich noch Luft gewesen wäre.
gepostet vor 17 Jahre, 11 Monate von bed
In diesem Zusammenhang duerften auch sar iostat und konsorten interessant sein. In meinem Blog habe ich da mal letztes Jaghr was geschrieben
isag-System-Activity-Grapher
Bei einem Suse Systgem in yast nach iostat suchen, das reicht auch
dstat faellt mir noch ein, ebenfalls ganz nett.
Und um Speicherfresser zu finden einfach mal mempeak installieren.
Im netz danach suchen, ist soweit ich weiss letztens von der Bildflaeche verschwunden.
mempeak sollte mit screen gestartet werden und kann ruhig mehrere Tage laufen, ohne das man eine sitzung offen lassen muss
mempeak und screen
isag-System-Activity-Grapher
Bei einem Suse Systgem in yast nach iostat suchen, das reicht auch
dstat faellt mir noch ein, ebenfalls ganz nett.
Und um Speicherfresser zu finden einfach mal mempeak installieren.
Im netz danach suchen, ist soweit ich weiss letztens von der Bildflaeche verschwunden.
mempeak sollte mit screen gestartet werden und kann ruhig mehrere Tage laufen, ohne das man eine sitzung offen lassen muss
mempeak und screen
gepostet vor 17 Jahre, 11 Monate von open_dimension
Ok, vielen Dank für die Tipps.
Ich wollte nur noch eben ergänzend hinzufügen, dass es ja ein VPS ist, und ich laut Vertrag 1 GB RAM zugesichert bekommen habe.
So nun sind auf meiner Maschine 15 weitere VPS, ABER nur 6 GB RAM, der Rest wird als Swap zur Verfügung gestellt. Jetzt habe ich den Verdacht, dass mein Provider viele Shooter-Server hostet, da die sind schon halbwegs vorinstalliert auf den Systemen sind. Und das sind Speicherfresser ohne Gleichen.
Deswegen hab ich den Apache so oft gestartet, und die anderen Einstellungen hoch geschraubt, dann steigt die Wahrscheinlichkeit im Speicher zu sein, und nicht in den Swap abgeschoben zu werden, deshalb auch die etwas überdimensionierte Datenbank.
Ich wollte nur noch eben ergänzend hinzufügen, dass es ja ein VPS ist, und ich laut Vertrag 1 GB RAM zugesichert bekommen habe.
So nun sind auf meiner Maschine 15 weitere VPS, ABER nur 6 GB RAM, der Rest wird als Swap zur Verfügung gestellt. Jetzt habe ich den Verdacht, dass mein Provider viele Shooter-Server hostet, da die sind schon halbwegs vorinstalliert auf den Systemen sind. Und das sind Speicherfresser ohne Gleichen.
Deswegen hab ich den Apache so oft gestartet, und die anderen Einstellungen hoch geschraubt, dann steigt die Wahrscheinlichkeit im Speicher zu sein, und nicht in den Swap abgeschoben zu werden, deshalb auch die etwas überdimensionierte Datenbank.
gepostet vor 17 Jahre, 11 Monate von Agmemon
Ich weiß nicht, ob das einfach zu übertragen ist, auf deine Anforderung, aber ich habe vor einiger Zeit einen interessanten Artikel über Skalierung auf FastCGI Basis gelesen. In dem Artikel gab es einen sehr schönen Ansatz, wie die Anzahl der laufenden FastCGI Instanzen bestimmt wurde, die benötigt werden, um eine optimale Performance zu bieten.
Der Server Betreiber hat einfach, auf Basis der Serverstatistiken, bestimmt, wie viele parallele Zugriffe er pro Sekunde auf das System hat. Und diesen Wert hat er genommen, und als Anzahl der FastCGI Prozesse konfiguriert, die ständig laufen sollen.
Der Server Betreiber hat einfach, auf Basis der Serverstatistiken, bestimmt, wie viele parallele Zugriffe er pro Sekunde auf das System hat. Und diesen Wert hat er genommen, und als Anzahl der FastCGI Prozesse konfiguriert, die ständig laufen sollen.
gepostet vor 17 Jahre, 11 Monate von unverbraucht
Ich würd auch ernsthaft überlegen, einen anderen Webserver einzusetzen. Apache hat Tradition, aber Single-Threaded Webserver machen in meinen Augen oft mehr Sinn. Als Open-Source-Lösung ist lighttpd recht beliebt, und kommerziell gibts den litespeed httpd, der auch eine optimierte FastCGI-Schnittstelle speziell für PHP mitbringt. Braucht auf jeden Fall weniger Speicher. Gerade mit den neuen Kernel-Schnittstellen wie epoll bei Linux scheinen monolithische Webserver die Nase vorn zu haben. Hab grad litespeed installiert, aber das mitgelieferte php ist Rotz
gepostet vor 17 Jahre, 11 Monate von Kampfhoernchen
Multi-Threatet ist zwar speicherintensiver, aber auf Hyperthreating oder sogar Multicore-Maschinen definitiv schneller, da hier Prozesse (Quasi-)gleichzeitig ablaufen (quasi nur bei HT)
gepostet vor 17 Jahre, 11 Monate von mifritscher
Und ich dachte immer das apache2 zumindest in der Voreinstellung mit dem prefork-modul zwar single-threaded, aber multi-processed ist und lighthttpd und Co. (meines Wissens auch der IIS) multithreaded sind *g*
gepostet vor 17 Jahre, 11 Monate von unverbraucht
Original von mifritscher
Und ich dachte immer das apache2 zumindest in der Voreinstellung mit dem prefork-modul zwar single-threaded, aber multi-processed ist und lighthttpd und Co. (meines Wissens auch der IIS) multithreaded sind *g*
Jetzt musste ich auch erstmal Googlen
Zitat:
lighty is a single-threaded, single-process, event-based, non-blocking-io webserver.
lighttpd ist auf jeden Fall Single-Threaded und macht intern alles über einen Eventhandler. Das mit dem Apache stimmt so natürlich, aber den kann man ja auch auf Single-Process, Multi-Threaded stellen - braucht trotzdem massenhaft Ressourcen.
Ich hab heute mal lighttpd für meine Entwicklungsbox aufgesetzt. Rein subjektiv ists ein wenig schneller, aber das sagt ja nix Wenn ich die Leute, mit denen ich mir einen Server teile zu lighttpd überreden kann mach ich nen Benchmark.
Original von Kampfhoernchen
Multi-Threatet ist zwar speicherintensiver, aber auf Hyperthreating oder sogar Multicore-Maschinen definitiv schneller, da hier Prozesse (Quasi-)gleichzeitig ablaufen (quasi nur bei HT)
Nicht unbedingt. Der kommerzielle litespeed server kann auf mehrere CPUs skalieren. Selbst lighttpd verteilt die Last zumindest bei PHP oder anderen Serverskriptsprachen recht gut, weil die einzelnen virtuellen Maschinen als persistente Prozesse laufen. Dann könnte zu einem Zeitpunkt PHP auf dem einen Kern, der Webserver auf dem zweiten und die DB auf dem dritten laufen usw.
gepostet vor 17 Jahre, 11 Monate von mifritscher
Hmm, dann verstehe ich nicht ganz wieso der lighthttpd so sparsam ist.
Dann muss ja der Thread dauernd zwischen den Aufgaben switchen. Entweder die haben einen großen Cache um alle Aufgaben zwischenzuspeichern oder die müssen dauernd z.B. die Datei erneut seeken, was nicht so schön für die CPU ist. Auch gefällt mir daran nicht dass wenn der eine Thread durch einen Fehler irgendwo im System hängt der ganze Server unbrauchbar rum.
"As lighty will wait for the disk, all connections in the process will have to wait. Here you should create 4-16 worker processes to be able to handle accepting new connections, sending out data and waiting for data in the same run."
- autsch, d.h. wenn jemand eine große, recht fragmentierte Datei herunterlädt gibt's ein Problem. Als Alternative wird vorgeschlagen 4-16 Prozesse zu erstellen, was ebensoviel mehr Speicher frisst.
Was passiert da eigentlich wenn php im Spiel ist? Da wird wohl auch geblockt, zumindest bis alle Daten drüben sind und fast_cgi mit der Ausführug begonnen hat?
Die Accesslogs sind dann wohl auch im Eimer:
"mod_accesslog might create broken accesslogs as the same file is opened twice and is NOT synchonized"
Also, so ganz ausgereift scheint mir das ganze noch nicht sein.
Mir fehlt auf der Seite ein Benchmark Apache2+php5 vs. lighthttpd+php5.
Apache1+php4 kommt ja schon auf 75% des Wertes von lighthttpd.
Auch würde mich mal interessieren wie sich ein multithreaded Apache2 so schlägt.
Ich habe mal wegen dem Speicherverbrauch geschaut: Bei mir hat ein Apache2-Process nur 3-4 MB Daten, der Rest ist Code, der zwischen allen Prozessen geshared wird.
Also ist der Speicherverbrauch ca. 10 MB+(x*4)...
Dann muss ja der Thread dauernd zwischen den Aufgaben switchen. Entweder die haben einen großen Cache um alle Aufgaben zwischenzuspeichern oder die müssen dauernd z.B. die Datei erneut seeken, was nicht so schön für die CPU ist. Auch gefällt mir daran nicht dass wenn der eine Thread durch einen Fehler irgendwo im System hängt der ganze Server unbrauchbar rum.
"As lighty will wait for the disk, all connections in the process will have to wait. Here you should create 4-16 worker processes to be able to handle accepting new connections, sending out data and waiting for data in the same run."
- autsch, d.h. wenn jemand eine große, recht fragmentierte Datei herunterlädt gibt's ein Problem. Als Alternative wird vorgeschlagen 4-16 Prozesse zu erstellen, was ebensoviel mehr Speicher frisst.
Was passiert da eigentlich wenn php im Spiel ist? Da wird wohl auch geblockt, zumindest bis alle Daten drüben sind und fast_cgi mit der Ausführug begonnen hat?
Die Accesslogs sind dann wohl auch im Eimer:
"mod_accesslog might create broken accesslogs as the same file is opened twice and is NOT synchonized"
Also, so ganz ausgereift scheint mir das ganze noch nicht sein.
Mir fehlt auf der Seite ein Benchmark Apache2+php5 vs. lighthttpd+php5.
Apache1+php4 kommt ja schon auf 75% des Wertes von lighthttpd.
Auch würde mich mal interessieren wie sich ein multithreaded Apache2 so schlägt.
Ich habe mal wegen dem Speicherverbrauch geschaut: Bei mir hat ein Apache2-Process nur 3-4 MB Daten, der Rest ist Code, der zwischen allen Prozessen geshared wird.
Also ist der Speicherverbrauch ca. 10 MB+(x*4)...
gepostet vor 17 Jahre, 11 Monate von Agmemon
Auch meine Tests haben gezeigt, dass Lighty schneller ist als Apache, auch wenn das nicht das Hauptziel der Betrachtung war: www.kueken.net/archives/2006/06/
Für mich spielt der Lighty seine Stärken im Bereich Skalierung aus. Über den Einsatz von FastCGI wird der Code einer Anwendung ja nicht mehr im Prozessraum des Webservers ausgeführt, sondern als eigenständiger Prozess. Damit entfallen die Probleme im klassischem LAMP Umfeld, die manchen von euch ja bekannt sein dürften. Zum Beispiel, wenn der Speicherverbrauch des Apaches so hoch geht, dass er anfängt zu swappen. Lighty wurde hingegen auf Hinblick auf das "C10K problem" entwickelt.
Unter Verwendung von FastCGI hat der Webserver ja dann auch kaum noch was zu tun, ausser Anfragen zu vermitteln und statische Dateien zur Verfügung zu stellen.
Apache kann ja nicht mehr mit vollem FastCGI Support aufwarten, da das Projekt nicht mehr weiterentwickelt wird und nur noch durch Community-Patches am Leben erhalten wird, um halbwegs für neue Apache Versionen zur Verfügung zu stehen.
Man muss aber darauf achten, dass Lighty in der Fachliteratur eher als "none stable" eingestuft wird, und ein Produktivbetrieb noch nicht wirklich empfohlen wird. Sieht man sich aber an, wo Lighty den Apache bereits verdrängt hat (Wikipedia, YouTube, Sourceforge, BILDBlog sind nur ein paar der bekannten Namen), zeigt sich schon, wie leistungsstark und zuverlässig der Lighty ist. YouTube gehört z.B. zur Kategorie mit über 100.000.000 Requests pro Tag.
Ob litespeed eine mögliche Alternative ist, weiß ich nicht. Mich schreckt schon die properitäre Schnittstelle LSAPI ab.
Für mich spielt der Lighty seine Stärken im Bereich Skalierung aus. Über den Einsatz von FastCGI wird der Code einer Anwendung ja nicht mehr im Prozessraum des Webservers ausgeführt, sondern als eigenständiger Prozess. Damit entfallen die Probleme im klassischem LAMP Umfeld, die manchen von euch ja bekannt sein dürften. Zum Beispiel, wenn der Speicherverbrauch des Apaches so hoch geht, dass er anfängt zu swappen. Lighty wurde hingegen auf Hinblick auf das "C10K problem" entwickelt.
Unter Verwendung von FastCGI hat der Webserver ja dann auch kaum noch was zu tun, ausser Anfragen zu vermitteln und statische Dateien zur Verfügung zu stellen.
Apache kann ja nicht mehr mit vollem FastCGI Support aufwarten, da das Projekt nicht mehr weiterentwickelt wird und nur noch durch Community-Patches am Leben erhalten wird, um halbwegs für neue Apache Versionen zur Verfügung zu stehen.
Man muss aber darauf achten, dass Lighty in der Fachliteratur eher als "none stable" eingestuft wird, und ein Produktivbetrieb noch nicht wirklich empfohlen wird. Sieht man sich aber an, wo Lighty den Apache bereits verdrängt hat (Wikipedia, YouTube, Sourceforge, BILDBlog sind nur ein paar der bekannten Namen), zeigt sich schon, wie leistungsstark und zuverlässig der Lighty ist. YouTube gehört z.B. zur Kategorie mit über 100.000.000 Requests pro Tag.
Ob litespeed eine mögliche Alternative ist, weiß ich nicht. Mich schreckt schon die properitäre Schnittstelle LSAPI ab.
gepostet vor 17 Jahre, 10 Monate von MannaZ
Agmemon, währest du vielleicht so nett dein Wissen im bereich Lighttpd mit uns zu teilen indem du uns lighty-Unwissenden eine Optimale(re) Konfiguration näher legst?
gepostet vor 17 Jahre, 10 Monate von Agmemon
Um zu verstehen, wie man es mit lighty besser machen kann, muss man erstmal verstehen, wo das Problem beim Apache liegt. Ich möchte allerdings vorweg sagen, dass der Apache ein wunderbares Produkt ist und zu Recht einen Marktanteil von 70% hat. Es geht nur darum, warum lighty für gewisse Szenarien besser geeignet ist.
Für jeden Request, der beim Apache eingeht, wird eine neue Instanz erstellt. Wenn ich es richtig im Kopf habe, kann es gerade nicht testen, hat der alte Apache (1.x) für jeden Request geforkt und der neue Apache (2.x) erstellt Threads. Bin mir aber nicht ganz sicher. Innerhalb dieser Instanz wird dann die Seite generiert und an den Benutzer ausgeliefert. Bei 50 parallelen Anfragen heißt dass, das 50 parallele Apache-Instanzen im gleichen Prozessraum laufen, und somit auf die gleichen Prozessinformationen und Speicherbereich zugreifen. Daraus resultiert: je mehr parallele Zugriffe geschehen, desto höher ist der Speicherverbrauch des Apache-Prozesses. Bei statischen Seiten ist das noch nicht so schlimm, aber bei dynamischen Seiten kommt noch ein Faktor hinzu.
Nutzt man z.B. PHP über CGI wird in jeder Instanz zunächst der PHP-Prozessor geladen, das Skript geladen, abgearbeitet und dann die Seite ausgeliefert. Bei 50 parallelen Zugriffen heißt das, dass der PHP-Prozessor 50 mal geladen wird und sich ebenfalls im Prozessraum das Apaches befindet und auch 50 mal der Speicher für den PHP-Prozessor benötigt wird.
Nutzt man hingegen mod_php, wird der PHP-Prozessor schon beim Start des Apaches mit geladen und steht den Instanzen schon zur Verfügung.
Fügt man diese Informationen zusammen, kommt man zum typischen Problem von Apache bei einer hohen Anzahl von parallelen Anfragen. Der Apache fängt an zu swappen und legt damit alle Instanzen lahm, da sie ja alle im gleichen Prozess- und Speicherraum liegen.
Was macht lighty nun anders? Zunächst mal erstellt lighty nicht für jeden Request eine eigene Instanz. Wie das genau gemacht wird, habe ich auch noch nicht gefunden und habe bisher auch gescheut, in den Quelltext zu gucken. Daraus resultiert, dass der Speicherverbrauch von lighty geringer ist.
Zum Generieren von dynamischen Seiten kommt FastCGI zum Einsatz. In der Konfigurationsdatei von lighty, wird definiert, wo welche Skripte liegen, die über FastCGI genutzt werden sollen. Das sieht z.B. so aus:
"min-procs" => 1,
"max-procs" => 1,
"socket" => "tmp/sockets/fcgi.socket",
"bin-path" => "public/dispatch.fcgi",
"bin-environment" => ( "RAILS_ENV" => "development" )
) ) )
In dieser Konfiguration steht also, dass beim Start des lighty, das Script dispatch.fcgi als eigenständiger Prozess gestartet werden soll und über die FastCGI Schnittstelle verfügbar sein soll. Der erste Vorteil dabei ist, dass das Skript wirklich in einem eigenem Prozess gestartet wird, mit eigenem Prozess- und Speicherraum und damit unabhängig von light läuft. Der zweite Vorteil liegt darin, dass ein FastCGI-Skript aus zwei Bereichen besteht. Im ersten Bereich können initialisierungen vorgenommen werden, z.B. eine Datenbankverbindung aufbauen, Config-Dateien eingelesen, und so weiter. Im zweiten Bereich befindet sich dann das eigentliche Skript, welches ausgeführt wird, wenn das Skript durch einen Request aufgerufen wird.
Was heißt das in der Praxis? Nehmen wir mal ein typisches PHP Skript, das ein paar Dateien includiert, eine Verbindung zur DB aufbaut, ein paar Daten abfragt und daraus eine Seite generiert. Mit dem Start des Lighty wird also das Skript geladen, die Laufzeitumgebung für die Sprache gestartet, die notwendigen Dateien includiert und die Verbindung zur DB aufgebaut. Kommt nun ein Request rein, fallen diese Punkte weg, weil schon erledigt und es wird nur noch die Abfrage ausgeführt und die Seite generiert. Dann geht das Skript wieder in Wartestellung und wartet auf die nächste Anfrage.
Jetzt ist es natürlich klar, dass ein Prozess in dem ein Skript läuft, nicht genug ist, um viele Anfragen abzuarbeiten. Daher kann man Lighty anweisen, mehrere Prozesse mit dem gleichen Skript zu starten, auf die dann die Anfragen verteilt werden.
Und damit ist man beim Punkt der lokalen Skalierung angekommen. Wenn man weiß, welche Skript sehr häufig aufgerufen werden, startet man davon mehr Prozesse wobei man bei einem Skript, das nur selten genutzt wird, mit weniger Prozessen auskommen kann.
Wenn man aber an den Punkt kommt, dass ein Server nicht mehr auskommt, kann man es auch so konfigurieren, dass die FastCGI-Prozesse auf anderen Rechnern gestartet werden. Während lighty auf Server1 läuft, läuft ScriptA aus Server2, ScriptB auf Server3 und so weiter. Und das ist ein typisches Skalierungsverfahren in dem Umfeld. Nach aussen hin läuft ein Server mit lighty, der nichts anderes macht, als statische Dateien auszuliefern und Anfragen auf dynamische Inhalte zu vermitteln. Damit ist er nicht ausgelastet und kann so viel mehr parallele Anfragen verarbeiten, als Apache. Und dahinter stehen dann n Server auf denen die Skripte liegen. Kein Round-Robin, keine DNS Spielerein, einfach zu erweitern.
Der Fairnesshalber muss man noch sagen, dass es auch FastCGI für Apache gibt. Leider aber nicht mehr für die aktuellen Versionen, da das Projekt eingestellt wurde. Es gibt zwar noch inoffizielle Patches von Benutzern, aber so richtig funktionieren tut es nicht. Dazu kommt, dass beim Apache das Problem mit den Instanzen für jeden Request weiterhin besteht und ich dunkel in Erinnerung habe, dass es diese Lastverteilung in der Form nicht gibt.
Genug zur Theorie, Zeit zu zeigen, dass das keine heiße Luft ist. Benchmarks sind ja ganz nett, aber Beispiele aus dem echten Leben sind besser. Hier ist ein Artikel, von einer Seite, die es probiert haben. Ich vermute mal, dass der Erfolg nicht nur am Wechsel von Apache zu lighty ausschlaggebend war, sondern das es auch Unterschiede in der PHP-FastCGI Unterstützung gab. Aber trotzdem spricht ein viertel Speicherverbrauch durch das Lighty-System gegenüber Apache eine deutliche Sprache:
weblog.textdrive.com/article/44/taking-a-full-frontal-slashdot-lighttpdly
P.S.: Ich habe gerade gesehen, dass Lighty mit dem FastCGI-PHP Binding jetzt auch eAccelerator unterstützt. Also wenn da jemand Erfahrung mit macht, würden mich die Zahlen mal interessieren.
Für jeden Request, der beim Apache eingeht, wird eine neue Instanz erstellt. Wenn ich es richtig im Kopf habe, kann es gerade nicht testen, hat der alte Apache (1.x) für jeden Request geforkt und der neue Apache (2.x) erstellt Threads. Bin mir aber nicht ganz sicher. Innerhalb dieser Instanz wird dann die Seite generiert und an den Benutzer ausgeliefert. Bei 50 parallelen Anfragen heißt dass, das 50 parallele Apache-Instanzen im gleichen Prozessraum laufen, und somit auf die gleichen Prozessinformationen und Speicherbereich zugreifen. Daraus resultiert: je mehr parallele Zugriffe geschehen, desto höher ist der Speicherverbrauch des Apache-Prozesses. Bei statischen Seiten ist das noch nicht so schlimm, aber bei dynamischen Seiten kommt noch ein Faktor hinzu.
Nutzt man z.B. PHP über CGI wird in jeder Instanz zunächst der PHP-Prozessor geladen, das Skript geladen, abgearbeitet und dann die Seite ausgeliefert. Bei 50 parallelen Zugriffen heißt das, dass der PHP-Prozessor 50 mal geladen wird und sich ebenfalls im Prozessraum das Apaches befindet und auch 50 mal der Speicher für den PHP-Prozessor benötigt wird.
Nutzt man hingegen mod_php, wird der PHP-Prozessor schon beim Start des Apaches mit geladen und steht den Instanzen schon zur Verfügung.
Fügt man diese Informationen zusammen, kommt man zum typischen Problem von Apache bei einer hohen Anzahl von parallelen Anfragen. Der Apache fängt an zu swappen und legt damit alle Instanzen lahm, da sie ja alle im gleichen Prozess- und Speicherraum liegen.
Was macht lighty nun anders? Zunächst mal erstellt lighty nicht für jeden Request eine eigene Instanz. Wie das genau gemacht wird, habe ich auch noch nicht gefunden und habe bisher auch gescheut, in den Quelltext zu gucken. Daraus resultiert, dass der Speicherverbrauch von lighty geringer ist.
Zum Generieren von dynamischen Seiten kommt FastCGI zum Einsatz. In der Konfigurationsdatei von lighty, wird definiert, wo welche Skripte liegen, die über FastCGI genutzt werden sollen. Das sieht z.B. so aus:
fastcgi.server = ( ".fcgi" => ( "localhost" => (
"min-procs" => 1,
"max-procs" => 1,
"socket" => "tmp/sockets/fcgi.socket",
"bin-path" => "public/dispatch.fcgi",
"bin-environment" => ( "RAILS_ENV" => "development" )
) ) )
In dieser Konfiguration steht also, dass beim Start des lighty, das Script dispatch.fcgi als eigenständiger Prozess gestartet werden soll und über die FastCGI Schnittstelle verfügbar sein soll. Der erste Vorteil dabei ist, dass das Skript wirklich in einem eigenem Prozess gestartet wird, mit eigenem Prozess- und Speicherraum und damit unabhängig von light läuft. Der zweite Vorteil liegt darin, dass ein FastCGI-Skript aus zwei Bereichen besteht. Im ersten Bereich können initialisierungen vorgenommen werden, z.B. eine Datenbankverbindung aufbauen, Config-Dateien eingelesen, und so weiter. Im zweiten Bereich befindet sich dann das eigentliche Skript, welches ausgeführt wird, wenn das Skript durch einen Request aufgerufen wird.
Was heißt das in der Praxis? Nehmen wir mal ein typisches PHP Skript, das ein paar Dateien includiert, eine Verbindung zur DB aufbaut, ein paar Daten abfragt und daraus eine Seite generiert. Mit dem Start des Lighty wird also das Skript geladen, die Laufzeitumgebung für die Sprache gestartet, die notwendigen Dateien includiert und die Verbindung zur DB aufgebaut. Kommt nun ein Request rein, fallen diese Punkte weg, weil schon erledigt und es wird nur noch die Abfrage ausgeführt und die Seite generiert. Dann geht das Skript wieder in Wartestellung und wartet auf die nächste Anfrage.
Jetzt ist es natürlich klar, dass ein Prozess in dem ein Skript läuft, nicht genug ist, um viele Anfragen abzuarbeiten. Daher kann man Lighty anweisen, mehrere Prozesse mit dem gleichen Skript zu starten, auf die dann die Anfragen verteilt werden.
Und damit ist man beim Punkt der lokalen Skalierung angekommen. Wenn man weiß, welche Skript sehr häufig aufgerufen werden, startet man davon mehr Prozesse wobei man bei einem Skript, das nur selten genutzt wird, mit weniger Prozessen auskommen kann.
Wenn man aber an den Punkt kommt, dass ein Server nicht mehr auskommt, kann man es auch so konfigurieren, dass die FastCGI-Prozesse auf anderen Rechnern gestartet werden. Während lighty auf Server1 läuft, läuft ScriptA aus Server2, ScriptB auf Server3 und so weiter. Und das ist ein typisches Skalierungsverfahren in dem Umfeld. Nach aussen hin läuft ein Server mit lighty, der nichts anderes macht, als statische Dateien auszuliefern und Anfragen auf dynamische Inhalte zu vermitteln. Damit ist er nicht ausgelastet und kann so viel mehr parallele Anfragen verarbeiten, als Apache. Und dahinter stehen dann n Server auf denen die Skripte liegen. Kein Round-Robin, keine DNS Spielerein, einfach zu erweitern.
Der Fairnesshalber muss man noch sagen, dass es auch FastCGI für Apache gibt. Leider aber nicht mehr für die aktuellen Versionen, da das Projekt eingestellt wurde. Es gibt zwar noch inoffizielle Patches von Benutzern, aber so richtig funktionieren tut es nicht. Dazu kommt, dass beim Apache das Problem mit den Instanzen für jeden Request weiterhin besteht und ich dunkel in Erinnerung habe, dass es diese Lastverteilung in der Form nicht gibt.
Genug zur Theorie, Zeit zu zeigen, dass das keine heiße Luft ist. Benchmarks sind ja ganz nett, aber Beispiele aus dem echten Leben sind besser. Hier ist ein Artikel, von einer Seite, die es probiert haben. Ich vermute mal, dass der Erfolg nicht nur am Wechsel von Apache zu lighty ausschlaggebend war, sondern das es auch Unterschiede in der PHP-FastCGI Unterstützung gab. Aber trotzdem spricht ein viertel Speicherverbrauch durch das Lighty-System gegenüber Apache eine deutliche Sprache:
weblog.textdrive.com/article/44/taking-a-full-frontal-slashdot-lighttpdly
P.S.: Ich habe gerade gesehen, dass Lighty mit dem FastCGI-PHP Binding jetzt auch eAccelerator unterstützt. Also wenn da jemand Erfahrung mit macht, würden mich die Zahlen mal interessieren.
gepostet vor 17 Jahre, 10 Monate von mifritscher
Was mir beim lighty gar nicht gefällt ist dass er nur 1 Sache gleichzeitig machen kann. Ok, er kann die php-Ausführung auslagern und dabei was anderes machen, er kann aber z.B. nur 1 http-header gleichzeitig analysieren, Daten senden etc. Man kann zwar mehrere lighty-Prozesse starten, dann fällt aber der Vorteil entgültig weg, und beim Lighty hat man dann noch das Problem dass z.B. der Zugriff auf die log-files nicht serialisiert wird, da kommt bei häufigen Zugriffen oftmals eine bunte Mixtur raus.
Btw kann man auch den Apachen zwingen weniger Prozesse zu machen, sie kommen dann halt wie bei lighty in eine Warteliste. Ok, der Apache ist für diesen Betrieb nicht sonderlich optimiert, und da ist fastcgi ein absolutes Muss.
Lighty hat meiner Meinung nach nur einen Vorteil, wenn der php-Präprozessor relativ wenig gebraucht wird, z.B. 5% aller Aufrufe, Bilder etc mitgerechnet, die dann aber sehr lange brauchen, weil dann beim Apachen sehr viele php-Interpreter nutzlos im Speicher rumhängen, während lighty es dem fastcgi-Dämon übergibt und sich um die nächsten Aufträge kümmert.
Bei Einsatz von apc, eaccelerator etc. liegen die durchschnittlichen Rechen-/Latenzzeiten bei mod_php bei weit unter 10 ms, wenn nicht grad ein HDD-Zugriff erfolgt. Lighty blockiert aber bei einem HDD-Zugriff auf statische Daten komplett, lässt also keinerlei Zugriffe zu...
Was mir beim Artikel nicht gefällt ist die load. Lighty hat dafür eine interne Warteschlange, mich würde die Länge derselben mal interessieren.
Mich würde mal eine hochoptimierten Apache2+mod_php/fastcgi+apc/ea vs. genauso gut optimierten Lighty+fastcgi+apc/ea auf Single Core, Multi Core und Cluster interessieren, hier auch die unterschiedlichen Modelle (multithreaded vs. prefork beim Apachen bzw. 1 vs x Prozesse beim Lighty).
Da die Load/interne Warteschlange, CPU-Auslastung aufgeschlüsselt in User/System/Waiting, ram-verbrauch und Requests pro Sekunde.
Eventuell die max. Request/sec, dass die durchschnittliche Wartezeit 5,10,50, 100,500,1000 ms beträgt (ein bekannter DB-Bench macht's ähnlich, mir fällt nur der Name grad nicht ein).
Eventuell noch nach statischen Dateien (x aus 100 MB und 100 GB, um zu schauen wie sie mit hoher HDD-(Zugriffs)Last zurecht kommen), kleine php-Dateien und große php-Dateien getrennt, zusätzlich noch ein bunter Mix.
Ich kann es leider mangels Maschinen nicht :-(
Btw kann man auch den Apachen zwingen weniger Prozesse zu machen, sie kommen dann halt wie bei lighty in eine Warteliste. Ok, der Apache ist für diesen Betrieb nicht sonderlich optimiert, und da ist fastcgi ein absolutes Muss.
Lighty hat meiner Meinung nach nur einen Vorteil, wenn der php-Präprozessor relativ wenig gebraucht wird, z.B. 5% aller Aufrufe, Bilder etc mitgerechnet, die dann aber sehr lange brauchen, weil dann beim Apachen sehr viele php-Interpreter nutzlos im Speicher rumhängen, während lighty es dem fastcgi-Dämon übergibt und sich um die nächsten Aufträge kümmert.
Bei Einsatz von apc, eaccelerator etc. liegen die durchschnittlichen Rechen-/Latenzzeiten bei mod_php bei weit unter 10 ms, wenn nicht grad ein HDD-Zugriff erfolgt. Lighty blockiert aber bei einem HDD-Zugriff auf statische Daten komplett, lässt also keinerlei Zugriffe zu...
Was mir beim Artikel nicht gefällt ist die load. Lighty hat dafür eine interne Warteschlange, mich würde die Länge derselben mal interessieren.
Mich würde mal eine hochoptimierten Apache2+mod_php/fastcgi+apc/ea vs. genauso gut optimierten Lighty+fastcgi+apc/ea auf Single Core, Multi Core und Cluster interessieren, hier auch die unterschiedlichen Modelle (multithreaded vs. prefork beim Apachen bzw. 1 vs x Prozesse beim Lighty).
Da die Load/interne Warteschlange, CPU-Auslastung aufgeschlüsselt in User/System/Waiting, ram-verbrauch und Requests pro Sekunde.
Eventuell die max. Request/sec, dass die durchschnittliche Wartezeit 5,10,50, 100,500,1000 ms beträgt (ein bekannter DB-Bench macht's ähnlich, mir fällt nur der Name grad nicht ein).
Eventuell noch nach statischen Dateien (x aus 100 MB und 100 GB, um zu schauen wie sie mit hoher HDD-(Zugriffs)Last zurecht kommen), kleine php-Dateien und große php-Dateien getrennt, zusätzlich noch ein bunter Mix.
Ich kann es leider mangels Maschinen nicht :-(
gepostet vor 17 Jahre, 10 Monate von Agmemon
Original von mifritscher
Bei Einsatz von apc, eaccelerator etc. liegen die durchschnittlichen Rechen-/Latenzzeiten bei mod_php bei weit unter 10 ms, wenn nicht grad ein HDD-Zugriff erfolgt. Lighty blockiert aber bei einem HDD-Zugriff auf statische Daten komplett, lässt also keinerlei Zugriffe zu...
In der neuen Version scheint er das nicht mehr zu machen. Durch den Einsatz von Async IO wartet er nicht mehr, bis der HDD Zugriff erledigt ist, sondern schickt die Anforderung und bekommt eine Mitteilung wenn er fertig ist. So kann Lighty in der Zwischenzeit weiter arbeiten.