Tipps um Apache schneller zu machen?

[powtac]

Hi Zusammen,
ich habe Apache Version 2. und PHP 4.3 local auf Win 98 laufen, doch teilweise brauchen meine Sript ziemlich lange um ausgeführt zu werden. Wie kann ich Apache tunen um die Scripte laufen zu lasen?
powtac

[MichaelB]

Hallo,

ich habe Apache Version 2. und PHP 4.3 local auf Win 98 laufen, doch teilweise brauchen meine Sript ziemlich lange um ausgeführt zu werden. Wie kann ich Apache tunen um die Scripte laufen zu lasen?

Ein Reverse-Proxy davor setzen. Ist aber nur dann wirklich gut, wenn Deine Skripte nicht viel dynamisches machen (DB-Abfragen die angezeigt werden usw.) sondern nur dazu benutzt werden HTML-Seiten zusammen zu setzen.

Gruß
   MichaelB

[Christoph Schnauß]

hi,

Wie kann ich Apache tunen um die Scripte laufen zu lasen?
Ein Reverse-Proxy davor setzen

Hm. Kannst du noch schnell sagen, warum, und was für ein Proxy das sein soll?

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Hi!

Wie kann ich Apache tunen um die Scripte laufen zu lasen?
Ein Reverse-Proxy davor setzen

Hm. Kannst du noch schnell sagen, warum, und was für ein Proxy das sein soll?

z.B. 2. Apache mit mod_proxy oder Squid. Hat den Vorteil dass die Webserver besser für die entsprechenden Einsatzzwecke optimieren kannst. Mal angenommen Du hast in PHP sehr viele Module, womöglich das Schlachtschiff von Oracle-Client, dann werden Deine Apache-Prozesse schnell 12, 15 oder sogar 20 MB groß. Das ist natürlich absolute Ressourcen-Verschwendung für einen Requests der vielleicht nur eben ein 1-pixel.gif oder nur einen 304-Header senden muss. Dazu kommt, wenn Du dabei noch keep-alive verwendest, dass zig dieser Monster-Prozesse zwar im RAM liegen, aber für ne ganze Zeit nichts machen, weil sie an der aktuellen TCP-Verbindung auf einen neuen Request warten. Bei statischen Inhalten ist das prima, aber bei dynamischen wird das schnell teuer, weil Dein RAM in null-komma-nix voll ist und angefangen wird zu swappen.
Auch können persistente DB-Verbindungen in diesem Fall zu einem Problem/Hindernis werden.

Wenn Du jetzt aber einen 2., viel schlankeren Apachen davor setzt, der für statische Inhalte optimiert ist, und die Requests an PHP-Scripte an den anderen Apachen weiter leitest, dann hast du verhältnismäßig kleine Apache-Prozesse die sich um statischen Inhalt kümmern, und die großen Apache-Prozesse nur für die Requests an dynamische Inhalte.

Wenn man sogar einen Squid-Cache als Reverse-Proxy verwendet, dann wird das ganze nochmal schlanker, denn dieser kann dann die statischen Inhalte direkt im RAM halten. Das kann der Apache zwar auch, aber zum einen ist dies AFAIK noch nicht so 100%ig stabil implementiert, und der Squid ist gegenüber dem Apachen keine eierlegende Wollmilchsau, also erheblich Ressourcen-schonender als ein Apache je sein kann.

Bei der Gelegenheit sollte man sich auch mal den lighttpd ansehen, ist ein auf Performance getrimmter, sehr schlanker Webserver, welcher hervorragend mit PHP über fastcgi zusammenarbeitet.
http://incremental.de/products/lighttpd/download/

Grüße
Andreas

[Christoph Schnauß]

hallo Andreas,

Da hast du zwar viel Sinnvolles geschrieben, was man sich später mal aus dem Archiv verlinken kann, aber:

Hm. Kannst du noch schnell sagen, warum, und was für ein Proxy das sein soll?
z.B. 2. Apache mit mod_proxy oder Squid

Es geht um einen Apache 2.x.x unter Win98. mod_proxy halte ich unter Win98 nicht für sinnvoll (wenngleich es möglich ist) und SQUID läßt sich meines Wissens auf Win98 nicht einrichten.

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Hallo Christoph!

Hm. Kannst du noch schnell sagen, warum, und was für ein Proxy das sein soll?
z.B. 2. Apache mit mod_proxy oder Squid

Es geht um einen Apache 2.x.x unter Win98. mod_proxy halte ich unter Win98 nicht für sinnvoll (wenngleich es möglich ist) und SQUID läßt sich meines Wissens auf Win98 nicht einrichten.

Naja, das bezog sich auch weniger auf das diskutierte System, eher allgemein auf Deine Frage. Es hörte sich zumindest für mich so an als sei es eine prinzipielle Frage gewesen.
Außerdem finde ich das Thema interessant (wenn auch eher auf Linux-Systemen) ;-)

Das sowas auf einem Windows 98 System nicht viel Sinn macht ist schon klar, es wird wohl niemand auf die Idee kommen auf so einem System ernsthaft einen Webserver zu betreiben, außer zu lokalen Testzwecken. Und da die Apache-Unterstützung sowieso nur experimentell ist sollte man froh sein wenn es überhaupt läuft ;-)
Ich weiß ja auch nicht was der AP als "langsam" bezeichnet. Wie langsam? 2 Sekunden? 5 Sekunden? 20 Sekunden?... Und ich weiß auch nicht ob er auf den Webserver über das Netzwerk zugreift.
Noch eine Frage wäre wie er den Apache-Zugriff auf die PHP-Scripte konfiguriert hat usw.

Ich denke mir halt wenn die in der Doku schon an allen möglichen Stellen schreiben "experimental"... "highly experimental"... liegt es irgendwo nahe dass das Problem halt hiermit zu tun hat - und dann kann man lange suchen... ich würde froh sein wenn es geht, wenn man ernsthaft mit Apache arbeiten will sollte man IMHO ein etwas neueres Betriebssystem verwenden, auch zum lokalen Testen, wenn es denn wichtig ist.

Grüße
Andreas

[Christoph Schnauß]

morgens,

Außerdem finde ich das Thema interessant (wenn auch eher auf Linux-Systemen) ;-)

Na klar ist es ein interessantes Thema, und was du geschrieben hast, enthält schon eine Menge interessanter Denkansätze.

Das sowas auf einem Windows 98 System nicht viel Sinn macht ist schon klar, es wird wohl niemand auf die Idee kommen auf so einem System ernsthaft einen Webserver zu betreiben, außer zu lokalen Testzwecken.

Ich fürchte, daß das ein Irrtum ist, wie man ja am OP sieht (so klar hat er sich allerdings nicht ausgedrückt). Wir sehen es aber an vielen Apache-Nachfragen hier im Forum immer wieder, daß sich die Leute mal schnell einen Apache auf ihrer Windows-Kiste installieren  -  geht ja schön schnell  -  und dann Wunderdinge davon erwarten, ohne zu verstehen, was der Apache für ein Instrument ist.

Noch eine Frage wäre wie er den Apache-Zugriff auf die PHP-Scripte konfiguriert hat usw.

Das habe ich an anderer Stelle in diesem Thread auch anzusprechen versucht. mod_php4 ist zum Beispiel etwas ziemlich anderes als bloß die Hineinnahme von Direktiven wie
  AddType application/x-httpd-php .php
in die httpd.conf.

wenn man ernsthaft mit Apache arbeiten will sollte man IMHO ein etwas neueres Betriebssystem verwenden, auch zum lokalen Testen, wenn es denn wichtig ist.

ACK.

Allerdings wird mich jetzt die Idee beschäftigen, daß man einen zweiten Apache zwecks Performance-Gewinn "vorschalten" könnte. Ich habe kein Problem, zwei (oder auch mehr) Apache-Installationen parallel laufen zu lassen, aber ich bin noch nie auf die Idee gekommen, die gewissrmaßen in einem Cluster zusammenzubringen. Apache+Squid ist kein Thema, aber Apache+Apache ist mir noch nicht begegnet. Naja, wir haben ja demnächst ein paar Feiertage nacheinander und nach diversen Osterspaztiergängen bestimmt viel Zeit, etwas daran herumzuspielen ;-)

Grüße aus Berlin

Christoph S.

[Andreas Korthaus]

Moin ;-)

Noch eine Frage wäre wie er den Apache-Zugriff auf die PHP-Scripte konfiguriert hat usw.

Das habe ich an anderer Stelle in diesem Thread auch anzusprechen versucht. mod_php4 ist zum Beispiel etwas ziemlich anderes als bloß die Hineinnahme von Direktiven wie
  AddType application/x-httpd-php .php
in die httpd.conf.

Wie meinst Du das? Wenn Du PHP als Modul einbindest brauchst Du so eine Direktive, oder nicht? Bei CGI sieht das anders aus. Wobei ich das auf Windows schon seit Urzeiten schon nicht mehr gemacht habe ;-)

Allerdings wird mich jetzt die Idee beschäftigen, daß man einen zweiten Apache zwecks Performance-Gewinn "vorschalten" könnte.

Ob das wirklich so ein Gewinn ist - da bin ich selber noch gar nicht so sicher. Ich hatte noch keine Gelegenheit zu messen. Bei normaler Last werden vermutlich nur statische Inhalte marginal schneller, dynamische werden mit Sicherheit sogar langsamer - eben weil sie den Umweg über den Proxy nehmen müssen(wobei das vermutlich ebenfalls nur marginal ist...). Das was wirklich verbessert wird ist die Skalierbarkeit. Das heißt, Du kannst mit so einer Konstellation auf derselben Maschine vermutlich mehr Last bewältigen, also mit nur einem Apachen. Das schlägt sich unter hoher Last dann natürlich auch in der Laufzeit von Requests nieder.
Und natürlich ist es von da diesem Punkt an nur noch ein kleiner Schritt den 2. Apachen auf einen oder mehrere andere Rechner auszulagern.

Ich habe kein Problem, zwei (oder auch mehr) Apache-Installationen parallel laufen zu lassen, aber ich bin noch nie auf die Idee gekommen, die gewissrmaßen in einem Cluster zusammenzubringen.

Das Gute ist - Du braucht nur eine Apache-Installation! Du kannst den Apachen ja mit unterschiedlichen Konfig-Dateien starten(httpd -f).

Apache+Squid ist kein Thema, aber Apache+Apache ist mir noch nicht begegnet.

Gelesen habe ich das schon öfter. Aber nie probiert. Eigentlich finde ich die Squid-Version besser, aber ich muss gestehen in dem Bereich finde ich nicht viel Dokumentation, da in meinem Fall erschwerend hinzu kommt dass die ganze Geschichte auch mit SSL nach außen funktionieren muss.

Naja, wir haben ja demnächst ein paar Feiertage nacheinander und nach diversen Osterspaztiergängen bestimmt viel Zeit, etwas daran herumzuspielen ;-)

Dann mach das mal und berichte was bei rausgekommen ist ;-)

Ach ja, von wegen PHP+Apache2: http://simon.incutio.com/archive/2004/03/31/phpAndApache2

Grüße
Andreas

[serverAdmin]

Moin ;-)

Noch eine Frage wäre wie er den Apache-Zugriff auf die PHP-Scripte konfiguriert hat usw.

Das habe ich an anderer Stelle in diesem Thread auch anzusprechen versucht. mod_php4 ist zum Beispiel etwas ziemlich anderes als bloß die Hineinnahme von Direktiven wie
  AddType application/x-httpd-php .php
in die httpd.conf.

Wie meinst Du das? Wenn Du PHP als Modul einbindest brauchst Du so eine Direktive, oder nicht? Bei CGI sieht das anders aus. Wobei ich das auf Windows schon seit Urzeiten schon nicht mehr gemacht habe ;-)

Allerdings wird mich jetzt die Idee beschäftigen, daß man einen zweiten Apache zwecks Performance-Gewinn "vorschalten" könnte.
Ob das wirklich so ein Gewinn ist - da bin ich selber noch gar nicht so sicher. Ich hatte noch keine Gelegenheit zu messen. Bei normaler Last werden vermutlich nur statische Inhalte marginal schneller, dynamische werden mit Sicherheit sogar langsamer - eben weil sie den Umweg über den Proxy nehmen müssen(wobei das vermutlich ebenfalls nur marginal ist...). Das was wirklich verbessert wird ist die Skalierbarkeit. Das heißt, Du kannst mit so einer Konstellation auf derselben Maschine vermutlich mehr Last bewältigen, also mit nur einem Apachen. Das schlägt sich unter hoher Last dann natürlich auch in der Laufzeit von Requests nieder.
Und natürlich ist es von da diesem Punkt an nur noch ein kleiner Schritt den 2. Apachen auf einen oder mehrere andere Rechner auszulagern.

Ich habe kein Problem, zwei (oder auch mehr) Apache-Installationen parallel laufen zu lassen, aber ich bin noch nie auf die Idee gekommen, die gewissrmaßen in einem Cluster zusammenzubringen.
Das Gute ist - Du braucht nur eine Apache-Installation! Du kannst den Apachen ja mit unterschiedlichen Konfig-Dateien starten(httpd -f).

Apache+Squid ist kein Thema, aber Apache+Apache ist mir noch nicht begegnet.

Gelesen habe ich das schon öfter. Aber nie probiert. Eigentlich finde ich die Squid-Version besser, aber ich muss gestehen in dem Bereich finde ich nicht viel Dokumentation, da in meinem Fall erschwerend hinzu kommt dass die ganze Geschichte auch mit SSL nach außen funktionieren muss.

Naja, wir haben ja demnächst ein paar Feiertage nacheinander und nach diversen Osterspaztiergängen bestimmt viel Zeit, etwas daran herumzuspielen ;-)
Dann mach das mal und berichte was bei rausgekommen ist ;-)

Ach ja, von wegen PHP+Apache2: http://simon.incutio.com/archive/2004/03/31/phpAndApache2

Grüße
Andreas

hat jemand von euch erfahrung mit dem standalone freeware bundle, mit dem PHP mind. so schnell laufen soll wie mit APACHE. Gem NEWS group soll es unter http://80.122.30.155/wsphp/miniserv.zip als freeware verfügbar sein.

gruss
Admin

[powtac]

Ein Reverse-Proxy davor setzen. Ist aber nur dann wirklich gut, wenn Deine Skripte nicht viel dynamisches machen (DB-Abfragen die angezeigt werden usw.) sondern nur dazu benutzt werden HTML-Seiten zusammen zu setzen.

Ne, haut nicht hin, weil ich Apache brauche um meine dynamische(!) Skripte zu testen. Trozdem danke!!!!

[Andreas Korthaus]

Hallo!

Ein Reverse-Proxy davor setzen. Ist aber nur dann wirklich gut, wenn Deine Skripte nicht viel dynamisches machen (DB-Abfragen die angezeigt werden usw.) sondern nur dazu benutzt werden HTML-Seiten zusammen zu setzen.

Also das verstehe ich jetzt nicht, je komplexer die Scripte desto stärker der Effekt würde ich doch meinen, oder? Wenn die Scripte kaum was machen, was bringt das dann noch groß? Immerhin entsteht durch einen reverse-proxy auch zusätzlicher overhead, eben weil der Request 2 mal geparst werden muss, und noch per TCP weitergeleitet werden muss.

Grüße
Andreas

[MichaelB]

Hallo Andi,

Ein Reverse-Proxy davor setzen. Ist aber nur dann wirklich gut, wenn Deine Skripte nicht viel dynamisches machen (DB-Abfragen die angezeigt werden usw.) sondern nur dazu benutzt werden HTML-Seiten zusammen zu setzen.
Also das verstehe ich jetzt nicht, je komplexer die Scripte desto stärker der Effekt würde ich doch meinen, oder? Wenn die Scripte kaum was machen, was bringt das dann noch groß?

Naja. Ob die Skripte komplex sind oder nicht tut ja nichts zur Sache ob sie auch dynamisch sind.
Beispiel: Ein Skript welches ein Formularfeld auswertet und das Ergebnis anzeigt ist zwar einfach, aber der Inhalt ist eben dynamisch erzeugt. Damit fällt das Reverse-Proxy Konzept schon flach.
Wenn aber komplizerte Skripte verwendet werden nur um eine Seite aus verschiedenen Teilen zusammenzusetzen, spricht nix gegen Reverse-Proxy.

Immerhin entsteht durch einen reverse-proxy auch zusätzlicher overhead, eben weil der Request 2 mal geparst werden muss, und noch per TCP weitergeleitet werden muss.

Das stimmt. Da muss man halt abwägen bzw. testen.

Gruß
  MichaelB

[Andreas Korthaus]

Hi Michael!

Also das verstehe ich jetzt nicht, je komplexer die Scripte desto stärker der Effekt würde ich doch meinen, oder? Wenn die Scripte kaum was machen, was bringt das dann noch groß?
Naja. Ob die Skripte komplex sind oder nicht tut ja nichts zur Sache ob sie auch dynamisch sind.
Beispiel: Ein Skript welches ein Formularfeld auswertet und das Ergebnis anzeigt ist zwar einfach, aber der Inhalt ist eben dynamisch erzeugt. Damit fällt das Reverse-Proxy Konzept schon flach.

Wieso das? Der Reverse-Proxy leitet den Request weiter an den anderen Webserver, dieser erzeugt die mörderisch dynamische Ausgabe, und schickt das Ergebnis über den Reverse-Proxy wieder zurück an den Client. Warum soll das nicht gehen? Es geht hier ja nicht um Caching! Das geht auf HTTP-Ebene bei dynamischen Inhalte eh nur sehr schlecht wenn Du mich fragst.

Grüße
Andreas

[MichaelB]

Hi Andreas,

Also das verstehe ich jetzt nicht, je komplexer die Scripte desto stärker der Effekt würde ich doch meinen, oder? Wenn die Scripte kaum was machen, was bringt das dann noch groß?
Naja. Ob die Skripte komplex sind oder nicht tut ja nichts zur Sache ob sie auch dynamisch sind.
Beispiel: Ein Skript welches ein Formularfeld auswertet und das Ergebnis anzeigt ist zwar einfach, aber der Inhalt ist eben dynamisch erzeugt. Damit fällt das Reverse-Proxy Konzept schon flach.

Wieso das? Der Reverse-Proxy leitet den Request weiter an den anderen Webserver, dieser erzeugt die mörderisch dynamische Ausgabe, und schickt das Ergebnis über den Reverse-Proxy wieder zurück an den Client.

Aber eben nur einmal. Danach wird die Anfrage aus dem Cache gelesen. Deswegen geht das auch nicht mit Seiten die dynamisch auf Benutzereingaben reagieren. Da würde dann ja logischerweise der Cache das verhindern. Gecachte Seiten werden quasi so ausgeliefert wie statische.

Warum soll das nicht gehen? Es geht hier ja nicht um Caching!

Worum denn dann? Es ging daraum, bestimmte Dinge zu beschleunigen mit Hilfe eines Reverse-Proxy (Caching). Wenn ich das nicht will, wozu sollte ich dann einen Reverse-Proxy einsetzen?

Das geht auf HTTP-Ebene bei dynamischen Inhalte eh nur sehr schlecht wenn Du mich fragst.

Meine Rede ...

Gruß
   MichaelB

[Andreas Korthaus]

Hallo!

Wieso das? Der Reverse-Proxy leitet den Request weiter an den anderen Webserver, dieser erzeugt die mörderisch dynamische Ausgabe, und schickt das Ergebnis über den Reverse-Proxy wieder zurück an den Client.
Aber eben nur einmal. Danach wird die Anfrage aus dem Cache gelesen. Deswegen geht das auch nicht mit Seiten die dynamisch auf Benutzereingaben reagieren. Da würde dann ja logischerweise der Cache das verhindern. Gecachte Seiten werden quasi so ausgeliefert wie statische.

Das ist ja Konfiguratuions-Sache was der Proxy cached und was nicht, darauf habe ich ja Einfluss!

Warum soll das nicht gehen? Es geht hier ja nicht um Caching!
Worum denn dann? Es ging daraum, bestimmte Dinge zu beschleunigen mit Hilfe eines Reverse-Proxy (Caching). Wenn ich das nicht will, wozu sollte ich dann einen Reverse-Proxy einsetzen?

Z.B. aus den Gründen die ich hier beschrieben habe: [pref:t=77938&m=450398]

Grüße
Andreas

[MichaelB]

Hallo,

Wieso das? Der Reverse-Proxy leitet den Request weiter an den anderen Webserver, dieser erzeugt die mörderisch dynamische Ausgabe, und schickt das Ergebnis über den Reverse-Proxy wieder zurück an den Client.
Aber eben nur einmal. Danach wird die Anfrage aus dem Cache gelesen. Deswegen geht das auch nicht mit Seiten die dynamisch auf Benutzereingaben reagieren. Da würde dann ja logischerweise der Cache das verhindern. Gecachte Seiten werden quasi so ausgeliefert wie statische.
Das ist ja Konfiguratuions-Sache was der Proxy cached und was nicht, darauf habe ich ja Einfluss!

Dagegen habe ich auch nix gesagt. Hier sind wir sicher einer Meinung.

Warum soll das nicht gehen? Es geht hier ja nicht um Caching!
Worum denn dann? Es ging daraum, bestimmte Dinge zu beschleunigen mit Hilfe eines Reverse-Proxy (Caching). Wenn ich das nicht will, wozu sollte ich dann einen Reverse-Proxy einsetzen?
Z.B. aus den Gründen die ich hier beschrieben habe: [pref:t=77938&m=450398]

*nochmal_durchles*
Hm. Vielleicht stehe ich ja etwas auf dem Schlauch aber in dem Posting geht es im Zusammenhang mit Reverse-Proxy um Caching.
Wo ist denn der Widerspruch?

Gruß
  MichaelB

[Andreas Korthaus]

Hallo!

Worum denn dann? Es ging daraum, bestimmte Dinge zu beschleunigen mit Hilfe eines Reverse-Proxy (Caching). Wenn ich das nicht will, wozu sollte ich dann einen Reverse-Proxy einsetzen?
Z.B. aus den Gründen die ich hier beschrieben habe: [pref:t=77938&m=450398]
*nochmal_durchles*
Hm. Vielleicht stehe ich ja etwas auf dem Schlauch aber in dem Posting geht es im Zusammenhang mit Reverse-Proxy um Caching.
Wo ist denn der Widerspruch?

Die Idee dort hat weniger mit Caching zu tun, mehr  mit Optimierung der httpd-Prozesse für den jeweiligen Einsatz-Zweck. Statische Dokumente brauchen nur serh wenig und so laufen die über einen Webserver der nur wenig kann - dafür vergleichsweise schlanke Prozesse verwendet. Die dynamischen Dokumente brauchen meist mehr Module, und benötigen merh Funktionalität, wodurch die Prozesse um ein vielfaches größer werden können. Daher die Idee den ersten Webserver gleichzeitig als Reverse-Proxy einzusetzen, das heißt, er liefert selber statische Inhalte aus, und leitet Requests an dynamische Dokumente per ProxyPass an den 2. Webserver weiter, denn dann alle benötigten Module hat und dessen Prozesse erheblich größer sind als die des ersten Webservers/Reverse Proxys. Der 1. Webserver(Proxy) hört Port 80/443 an der Netzwerkkarte ab, der 2. Webserver(PHP...) hört Port 8080 auf localhost ab. Der Proxy reicht also Requests an localhost:8080 weiter.

Dadurch kann man die Ressourcen des Webservers besser ausnutzen.

Wenn Du einen Reverse-Proxy einsetzt - was verwendest Du dann? Apache(mod_proxy)? Oder Squid? Oder nochwas anderses?

Hast Du Erfahrung mit eine, Reverse-proxy in Zusammenhang mit SSL? Bei Apache kein Problem - aber bei Squid? Funktioniert das? Man könnte sich ja auch ein Szenario überlegen wie:

Squid an Netzwerkkarte Port 443, leitet Request weiter an:

-> Apache #1 (für statisches) an localhost:8080

oder

-> Apache #2 (für dynamisches) an localhost:8081

Was hälst Du davon?  Wobei man in diesem Fall eigentlich keine 2 Webserver-Instanzen braucht, denn wenn sich die statischen Inhalte kaum ändern wird der Squid die meisten Inhalte ja selber cachen. Nur - soweit ich weiß darf man bei SSL gar nicht cachen, oder sowas? Aber da es ja auf dem eigentlichen Server passiert - warum nicht? Kann man das wohl so machen? Mein Problem ist hier, ich finde einfach nicht genügend Informationen wie man einen Squid für dieses Szenario konfiguriert. Zum einen bezieht sich fast die gesamte Doku auf "normale" Proxies, und das bisschen was sich auf reverse-proxies bezieht verliert kein Wort zumn Thema SSL.

Viele Grüße
Andreas

[MichaelB]

Hallo Andreas,

Die Idee dort hat weniger mit Caching zu tun, mehr  mit Optimierung der httpd-Prozesse für den jeweiligen Einsatz-Zweck.

Ok. Soweit hatte ich es auch verstanden. Nur der untere Abschnitt bezog sich auf httpd in Zusammenarbeit mit Reverse-Proxy (und damit meinte ich z.B. Squid). Und der Proxy hostet ja keine Seiten selber sondern cached nur die Inhalte.

Statische Dokumente brauchen nur serh wenig und so laufen die über einen Webserver der nur wenig kann - dafür vergleichsweise schlanke Prozesse verwendet.
Die dynamischen Dokumente brauchen meist mehr Module, und benötigen merh Funktionalität, wodurch die Prozesse um ein vielfaches größer werden können.

Kurze Zwischenfrage:
Bei parallelen Zugriffen werden ja (wie Du auch schon sagtest) mehrere httpd-Prozesse geöffnet.
Ist es wirklich so, daß ein neu geöffneter Prozess so dick ist wie ein anderer?
Ich vermute mal, daß der Programmcode zwischen den Prozessen eh geshared wird und es nur ein eigener Stackframe/Dataframe pro Prozess gibt, so dass ein schlank konfigurierter httpd erstmal nicht soviel bringt. Richtig?
Der Overhead für den Stackframe sollte nicht allzu viel sein. Und Resourcen wie DB-Verbindungen sind ohnehin Prozessgebunden und werden beim fork nicht dupliziert. Was bleibt ist bei den Resourcen das von Dir schon angesprochene keep-alive. Idealerweise müsste ein Mechanismus existieren, der Anfragen auf Seiten die z.B. eine DB benötigen an alive-Prozesse weitergibt die ohnehin schon eine DB-Verbindung offen haben. Wird aber wohl nicht ganz so einfach zu realisieren sein.

Daher die Idee den ersten Webserver gleichzeitig als Reverse-Proxy einzusetzen, das heißt, er liefert selber statische Inhalte aus, und leitet Requests an dynamische Dokumente per ProxyPass an den 2. Webserver weiter, denn dann alle benötigten Module hat und dessen Prozesse erheblich größer sind als die des ersten Webservers/Reverse Proxys. Der 1. Webserver(Proxy) hört Port 80/443 an der Netzwerkkarte ab, der 2. Webserver(PHP...) hört Port 8080 auf localhost ab. Der Proxy reicht also Requests an localhost:8080 weiter.

Jo. Ich glaube ich habe kapiert.

Dadurch kann man die Ressourcen des Webservers besser ausnutzen.

Wenn Du einen Reverse-Proxy einsetzt - was verwendest Du dann? Apache(mod_proxy)? Oder Squid? Oder nochwas anderses?

Ich hatte eher an Squid gedacht der dann die statischen Seiten (auch statische Seiten mit DB-Zugriff, wobei die Funktionalität sich da auf reines Anzeigen beschränken müsste) vom Webserver nach dem ersten Zugriff cached.

Hast Du Erfahrung mit eine, Reverse-proxy in Zusammenhang mit SSL? Bei Apache kein Problem - aber bei Squid? Funktioniert das? Man könnte sich ja auch ein Szenario überlegen wie:

Squid an Netzwerkkarte Port 443, leitet Request weiter an:

-> Apache #1 (für statisches) an localhost:8080

oder

-> Apache #2 (für dynamisches) an localhost:8081

Was hälst Du davon?

Wie Du schon sagtest ...

Wobei man in diesem Fall eigentlich keine 2 Webserver-Instanzen braucht, denn wenn sich die statischen Inhalte kaum ändern wird der Squid die meisten Inhalte ja selber cachen.

... ist der Apache #1 eigentlich überflüssig.

Nur - soweit ich weiß darf man bei SSL gar nicht cachen, oder sowas?

Könnte ich mir auch vorstellen. Das wäre ja dann eine Art Man-in-the-middle-attack und genau das soll ja ssl verhindern.

Aber da es ja auf dem eigentlichen Server passiert - warum nicht?

Apache-intern mit mod_proxy könnte ich mir das durchaus vorstellen, weil es ja ein und derselbe Prozess ist.

Leider fehlt mir zu dem SSL-Thema die Erfahrung, als das ich dazu gesicherte Aussagen treffen kann.

Kann man das wohl so machen? Mein Problem ist hier, ich finde einfach nicht genügend Informationen wie man einen Squid für dieses Szenario konfiguriert.

Auch nicht hier? http://devel.squid-cache.org/ssl/

Was übrigens auch noch eine Anwendung für zwei getrennte Server ist (also Apache-Apache oder Squid-Apache) ist für eine gewisse Lastverteilung, indem man die beiden Sachen einfach auf unterschiedliche Rechner packt. Vorallem wenn man ein relativ hohen Anteil an statischen Seiten hat. Das bringt zusätzlich auch noch ein gewissen Schutz, da der Apache auf dem die Serverskripte laufen ja doch etwas anfälliger ist.

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Statische Dokumente brauchen nur serh wenig und so laufen die über einen Webserver der
nur wenig kann - dafür vergleichsweise schlanke Prozesse verwendet. Die dynamischen
Dokumente brauchen meist mehr Module, und benötigen merh Funktionalität, wodurch die
Prozesse um ein vielfaches größer werden können.
Kurze Zwischenfrage:
Bei parallelen Zugriffen werden ja (wie Du auch schon sagtest) mehrere httpd-Prozesse
geöffnet.

Richtig.

Ist es wirklich so, daß ein neu geöffneter Prozess so dick ist wie ein anderer?

Jain.
Prinzipiell muss der komplette Speicher, auch das Datasegment, kopiert werden. Aber (jetzt
kommts): heutige Unixoide haben eine sehr geniale fork()-Implementation. Der Speicher wird
erst on demand kopiert. Heisst: der fork()-Aufruf selber ist erstmal nicht so teuer, es wird
nur eine neue Prozess-Umgebung angelegt. Erst wenn der neue Prozess auf die Daten zugreift
werden diese dann auch in den Speicherbereich des neuen Prozesses kopiert.

Ich vermute mal, daß der Programmcode zwischen den Prozessen eh geshared wird und es nur
ein eigener Stackframe/Dataframe pro Prozess gibt,

Nein. Der Code muss für jeden Prozess ein weiteres mal in den Speicher geladen werden.

so dass ein schlank konfigurierter httpd erstmal nicht soviel bringt. Richtig?

Doch, der bringt eine Menge ;-)

Der Overhead für den Stackframe sollte nicht allzu viel sein. Und Resourcen wie
DB-Verbindungen sind ohnehin Prozessgebunden und werden beim fork nicht dupliziert.

Klar werden sie. Es wird eine exakte, 100%ige Kopie von dem Prozess angelegt. Deshalb
sollte man mit offenen DB-Handles oder ähnlichem auch nicht fork()en, es wird ein- und
dieselbe Verbindung benutzt in dem Fall.

Grüße,
 CK

[MichaelB]

Hallo Christian,

Ist es wirklich so, daß ein neu geöffneter Prozess so dick ist wie ein anderer?
Jain.

Ah ... eine eindeutige Antwort :-)

Prinzipiell muss der komplette Speicher, auch das Datasegment, kopiert werden. Aber (jetzt
kommts): heutige Unixoide haben eine sehr geniale fork()-Implementation. Der Speicher wird
erst on demand kopiert. Heisst: der fork()-Aufruf selber ist erstmal nicht so teuer, es wird
nur eine neue Prozess-Umgebung angelegt. Erst wenn der neue Prozess auf die Daten zugreift
werden diese dann auch in den Speicherbereich des neuen Prozesses kopiert.

Hier habe ich ein kleines Verständnisproblem. Wie im weiteren Verlauf des Postings klar wird, wird ja das Codesegment dupliziert. Und das muss ja schon beim fork() passieren (spätestens wenn der fork aber in einem eigenen Task ausgeführt wird). Und eine solche Duplizierung finde ich schon recht teuer.

Ich vermute mal, daß der Programmcode zwischen den Prozessen eh geshared wird und es nur
ein eigener Stackframe/Dataframe pro Prozess gibt,

Nein. Der Code muss für jeden Prozess ein weiteres mal in den Speicher geladen werden.

Das finde ich aber ungeschickt und ist aus meiner Sicht auch unnötig (es sei denn, man hat selbstmodifizierenden Code; wäre wenngleich auch ein schmutziger aber gangbarer Weg, um Informationen zwischen Child-Prozessen auszutauschen *lächel*).
Selbst Windows benutzt ja code-sharing (mindestens seit Version 3.0). Ich bezweifel deshalb mal stark, daß dies so ist.
Moment ... wozu hat man denn die Sourcen für Linux *nachles*
Mein Verdacht scheint sich zu bestätigen.
In linux/kernel/fork.c gibt es eine Funktion do_fork die das forking ausführt. Die enthält (soweit ich das überblicken kann) kein reload oder duplizieren von Programmcode.
Es wird eine neue Task-Struktur (task_struct; im wesentlichen interne Verwaltungsinformationen über den Task) angelegt sowie das Datensegment und das Stacksegment kopiert (bis auf den Rückgabewert des fork()-Aufrufes, anscheinend damit der Prozess erkennen kann ob er der Orginalprozess oder der geklonte Prozess ist oder weiß der Geier warum).
Wie das in brandaktuellen Version des Linux-Kernels gemacht wird, weiß ich nicht. Ich kann mir aber nicht vorstellen dass sie hier eine grundlegende Änderung vorgenommen haben.

so dass ein schlank konfigurierter httpd erstmal nicht soviel bringt. Richtig?

Doch, der bringt eine Menge ;-)

Der Overhead für den Stackframe sollte nicht allzu viel sein. Und Resourcen wie
DB-Verbindungen sind ohnehin Prozessgebunden und werden beim fork nicht dupliziert.
Klar werden sie. Es wird eine exakte, 100%ige Kopie von dem Prozess angelegt. Deshalb
sollte man mit offenen DB-Handles oder ähnlichem auch nicht fork()en, es wird ein- und
dieselbe Verbindung benutzt in dem Fall.

Ich würde sagen auch das ist so formuliert falsch.

Eher (so denk ich mir) ist es so, daß es ein httpd-Vaterprozess gibt der Anfragen entgegen nimmt und für diese zunächst ein eigenen Kindprozess erzeugt (sofern kein freier Kindprozess zur Verfügung steht) der diese Anfrage dann erst bearbeitet und die Antwort an den Browser zurückgibt. Die fork() wird also immer von diesem (keine Resourcen belegenden) Vaterprozess gemacht und nicht von einem laufenden Kindprozess der evtl. schon eine DB-Verbindung offen hat.

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Ich vermute mal, daß der Programmcode zwischen den Prozessen eh geshared wird und es nur
ein eigener Stackframe/Dataframe pro Prozess gibt,

Nein. Der Code muss für jeden Prozess ein weiteres mal in den Speicher geladen werden.
Das finde ich aber ungeschickt und ist aus meiner Sicht auch unnötig (es sei denn, man hat
selbstmodifizierenden Code; wäre wenngleich auch ein schmutziger aber gangbarer Weg, um
Informationen zwischen Child-Prozessen auszutauschen *lächel*).
Selbst Windows benutzt ja code-sharing (mindestens seit Version 3.0). Ich bezweifel
deshalb mal stark, daß dies so ist.

Tut mir leid, hier habe ich Quark erzählt. Ich war wohl etwas verwürrt.
Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.

Moment ... wozu hat man denn die Sourcen für Linux *nachles*
Mein Verdacht scheint sich zu bestätigen.
In linux/kernel/fork.c gibt es eine Funktion do_fork die das forking ausführt. Die enthält
(soweit ich das überblicken kann) kein reload oder duplizieren von Programmcode.

Nein, das tut sie in der Tat nicht.

Es wird eine neue Task-Struktur (task_struct; im wesentlichen interne
Verwaltungsinformationen über den Task) angelegt sowie das Datensegment und das
Stacksegment kopiert (bis auf den Rückgabewert des fork()-Aufrufes, anscheinend damit der
Prozess erkennen kann ob er der Orginalprozess oder der geklonte Prozess ist oder weiß
der Geier warum).

Korrekt. fork() gibt für den Kind-Prozess 0 zurück und die PID für den Eltern-Prozess.

so dass ein schlank konfigurierter httpd erstmal nicht soviel bringt. Richtig?

Doch, der bringt eine Menge ;-)

Der Overhead für den Stackframe sollte nicht allzu viel sein. Und Resourcen wie
DB-Verbindungen sind ohnehin Prozessgebunden und werden beim fork nicht dupliziert.
Klar werden sie. Es wird eine exakte, 100%ige Kopie von dem Prozess angelegt. Deshalb
sollte man mit offenen DB-Handles oder ähnlichem auch nicht fork()en, es wird ein- und
dieselbe Verbindung benutzt in dem Fall.
Ich würde sagen auch das ist so formuliert falsch.

Ne.

Eher (so denk ich mir) ist es so, daß es ein httpd-Vaterprozess gibt der Anfragen
entgegen nimmt und für diese zunächst ein eigenen Kindprozess erzeugt (sofern kein
freier Kindprozess zur Verfügung steht) der diese Anfrage dann erst bearbeitet und die
Antwort an den Browser zurückgibt.

Jo. Und wo habe ich etwas anderes behauptet? ;-)

Die fork() wird also immer von diesem (keine Resourcen belegenden) Vaterprozess gemacht

Falsch. Der Vaterprozess hat alle Module geladen, die Konfiguration geparsed, etc, pp.

und nicht von einem laufenden Kindprozess der evtl. schon eine DB-Verbindung offen hat.

Was hat das eine mit dem anderen zu tun? Du hast gesagt, eine DB-Verbindung wird durch
fork() nicht kopiert. Ich habe gesagt, das ist falsch, sie wird durchaus kopiert. Nun
erzählst du mir, dass der Apache-Main-Prozess keine DB-Handels offen hat. Äh, ja, und?
Weiter?

Grüße,
 CK

[MichaelB]

Hallo CK,

...

Tut mir leid, hier habe ich Quark erzählt.

Mach Dir nix draus. Passiert mir auch immer wieder. :-)

Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.

Sind die Module eigentlich quasi mit einkompiliert oder werden sie on-demand geladen? Im letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.

Korrekt. fork() gibt für den Kind-Prozess 0 zurück und die PID für den Eltern-Prozess.

Gut zu wissen. Falls man mal doch damit programmiert.

Der Overhead für den Stackframe sollte nicht allzu viel sein. Und Resourcen wie
DB-Verbindungen sind ohnehin Prozessgebunden und werden beim fork nicht dupliziert.
Klar werden sie. Es wird eine exakte, 100%ige Kopie von dem Prozess angelegt. Deshalb
sollte man mit offenen DB-Handles oder ähnlichem auch nicht fork()en, es wird ein- und
dieselbe Verbindung benutzt in dem Fall.
Ich würde sagen auch das ist so formuliert falsch.
Ne.

Na jetzt bin ich ja mal gespannt ...

Eher (so denk ich mir) ist es so, daß es ein httpd-Vaterprozess gibt der Anfragen
entgegen nimmt und für diese zunächst ein eigenen Kindprozess erzeugt (sofern kein
freier Kindprozess zur Verfügung steht) der diese Anfrage dann erst bearbeitet und die
Antwort an den Browser zurückgibt.

Jo. Und wo habe ich etwas anderes behauptet? ;-)

Ok. Direkt behauptet hast Du es nicht.

Die fork() wird also immer von diesem (keine Resourcen belegenden) Vaterprozess gemacht

Falsch. Der Vaterprozess hat alle Module geladen, die Konfiguration geparsed, etc, pp.

Das ist halt die Frage ob der Apache wirklich alle Module beim Start lädt oder erst on-demand. Den Apache-Quellcode habe ich dummerweise gerade nicht zur Hand. :-)

und nicht von einem laufenden Kindprozess der evtl. schon eine DB-Verbindung offen hat.

Was hat das eine mit dem anderen zu tun? Du hast gesagt, eine DB-Verbindung wird durch
fork() nicht kopiert. Ich habe gesagt, das ist falsch, sie wird durchaus kopiert. Nun
erzählst du mir, dass der Apache-Main-Prozess keine DB-Handels offen hat. Äh, ja, und?

Das war offenbar ein Missverständnis bzw. wir haben etwas aneinander vorbeigeredet.
Also nochmal:
Wenn Du ein Prozess forkst, der ein DB-Handle offen hat so hat der neue Prozess diesen Handle natürlich auch.
Ich habe aber behauptet, daß der Apache aber nicht so vorgeht sondern DB-Handles und andere Resourcen immer von Kindprozessen des httpd geöffnet werden wärend der Vaterprozess von dem die forks erzeugt werden natürlich keine offnen Handles hat. Dementsprechend hat der Apache auch kein Problem mit Resourcen (wie DB-Handles) beim forken.

Jetzt klar?

Alles in Hinblick auf die Ausgangsdiskussion in der es darum ging ob sich ein dedizierter Apache lohnt (weil beim forken zuviel Overhead entsteht) oder nicht. Und ich war eben der Meinung so groß ist der Resourcenverbrauch nicht als das sich ein abgespeckter Apache lohnt.
Mehr Klarheit würde bringen, wenn man wüßte ob Module on-demand geladen werden oder nicht. Das sie als eigene Dateien vorliegen spricht dafür. Die Art wie sich eingebunden werden dagegen. Wie ist das Ganze denn nun?

Gruß
   MichaelB

[MichaelB]

Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.
Sind die Module eigentlich quasi mit einkompiliert oder werden sie on-demand geladen? Im letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.

Wie ist das eigentlich beim Apache 2.0 oder höher? Setzt der nicht ohnehin mehr auf Threading statt forking? Dann würde das Problem noch mehr entschärft und ich sehe dann echt kein Benefit mehr für einen zweiten Apache (auf derselben Maschine) für statische Seiten.

[Christian Kruse]

Hallo MichaelB,

Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.
Sind die Module eigentlich quasi mit einkompiliert oder werden sie on-demand geladen? Im
letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.
Wie ist das eigentlich beim Apache 2.0 oder höher? Setzt der nicht ohnehin mehr auf Threading
statt forking?

Das ist abhängig vom MPM. Da hast du (unter Unix) momentan die Auswahl zwischen prefork, dem
herkömmlichen Modell wie es bisher auch war und worker, einem threaded MPM.

Dann würde das Problem noch mehr entschärft und ich sehe dann echt kein Benefit mehr für
einen zweiten Apache (auf derselben Maschine) für statische Seiten.

Nutzt man worker gibt es den auch nicht mehr. Da ist das Problem dann nur noch, dass das
Threading unter Linux unter aller Sau ist. Da sollte man auf NPTL umsteigen.

Grüße,
 CK

[MichaelB]

Hallo CK,

Das ist abhängig vom MPM. Da hast du (unter Unix) momentan die Auswahl zwischen prefork, dem
herkömmlichen Modell wie es bisher auch war und worker, einem threaded MPM.

Coole Sache. Unter einem Unix würde ich dann nämlich wohl eher bei forking bleiben. Diese Variante ist doch ein wenig robuster (und damit stabiler).

Dann würde das Problem noch mehr entschärft und ich sehe dann echt kein Benefit mehr für
einen zweiten Apache (auf derselben Maschine) für statische Seiten.

Nutzt man worker gibt es den auch nicht mehr. Da ist das Problem dann nur noch, dass das
Threading unter Linux unter aller Sau ist.

"Profis" nehmen deshalb auch auch Windows. Ein System von Profis, für Profis :-)))

Da sollte man auf NPTL umsteigen.

Das ist ja glücklicherweise endlich(!) unter Linux verfügbar.

Gruß
   MichaelB

PS: Weil wir gerade am diskutieren sind. Was hälst Du eigentlich von Frames? :-)

[Christian Kruse]

Hallo MichaelB,

Das ist abhängig vom MPM. Da hast du (unter Unix) momentan die Auswahl zwischen prefork,
dem herkömmlichen Modell wie es bisher auch war und worker, einem threaded MPM.
Coole Sache. Unter einem Unix würde ich dann nämlich wohl eher bei forking bleiben. Diese
Variante ist doch ein wenig robuster (und damit stabiler).

Vor allem sind viele Sachen, die indirekt eingebunden werden (z. B. durch mod_php) noch
nicht Threadsafe.

Da sollte man auf NPTL umsteigen.
Das ist ja glücklicherweise endlich(!) unter Linux verfügbar.

Jor.

PS: Weil wir gerade am diskutieren sind. Was hälst Du eigentlich von Frames? :-)

Abstand.

Grüße,
 CK

[MichaelB]

Hallo CK,

Coole Sache. Unter einem Unix würde ich dann nämlich wohl eher bei forking bleiben. Diese
Variante ist doch ein wenig robuster (und damit stabiler).

Vor allem sind viele Sachen, die indirekt eingebunden werden (z. B. durch mod_php) noch
nicht Threadsafe.

Ah ... gut zu wissen. Und was machen da die Windowsler, bei denen das forking ja nicht soooo gut funktioniert? Aber wer betreibt schon ernsthaft ein Webserver auf Windows.

PS: Weil wir gerade am diskutieren sind. Was hälst Du eigentlich von Frames? :-)

Abstand.

Ich wußte, daß dieser Cheatah-Spruch kommt. Klärt aber noch nicht das Warum. :-)

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.
Sind die Module eigentlich quasi mit einkompiliert oder werden sie on-demand geladen? Im
letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.

Weder, noch. Man kann sie statisch mit einkompilieren, man kann sie aber auch dynamisch
laden lassen. Allerdings werden die Module beim Startup geladen.

Die fork() wird also immer von diesem (keine Resourcen belegenden) Vaterprozess gemacht

Falsch. Der Vaterprozess hat alle Module geladen, die Konfiguration geparsed, etc, pp.
Das ist halt die Frage ob der Apache wirklich alle Module beim Start lädt oder erst
on-demand. Den Apache-Quellcode habe ich dummerweise gerade nicht zur Hand. :-)

Er lädt sie direkt. Er *muss* sie sogar direkt laden. Jedes Modul kann
Konfigurations-Direktiven definieren. Die werden erst bekannt, wenn das Modul geladen ist.
Sind sie unbekannt, muss der Apache sie monieren.

[...]
Ich habe aber behauptet, daß der Apache aber nicht so vorgeht sondern DB-Handles und
andere Resourcen immer von Kindprozessen des httpd geöffnet werden wärend der
Vaterprozess von dem die forks erzeugt werden natürlich keine offnen Handles hat.
Dementsprechend hat der Apache auch kein Problem mit Resourcen (wie DB-Handles) beim
forken.

Das hängt davon ab, wie das Modul, dass diese Ressourcen benutzt, programmiert ist.
Prinzipiell kann das Modul auch vor dem fork() bereits Ressourcen allokieren.

Alles in Hinblick auf die Ausgangsdiskussion in der es darum ging ob sich ein dedizierter
Apache lohnt (weil beim forken zuviel Overhead entsteht) oder nicht. Und ich war eben
der Meinung so groß ist der Resourcenverbrauch nicht als das sich ein abgespeckter Apache
lohnt.

Das tut es in jedem Fall. a) wegen des gerigeren Aufwands beim fork() und b) wegen des
geringeren Speicherverbrauchs.

Mehr Klarheit würde bringen, wenn man wüßte ob Module on-demand geladen werden oder nicht.
Das sie als eigene Dateien vorliegen spricht dafür. Die Art wie sich eingebunden werden
dagegen. Wie ist das Ganze denn nun?

Der Apache-Startup läuft in drei Phasen:

Phase 1: grobes durchscannen der Konfigurations-Datei(en), so dass erkannt werden kann,
         welche Module geladen werden sollen.
Phase 2: Laden der Module und Handshaking mit ihnen (bekanntmachen der
         Konfigurations-Direktiven, Registrieren, etc, pp).
Phase 3: Genaues parsen der Konfigurations-Datei(en).

Die Module bleiben geladen solange der Apache läuft und werden kein zweites mal geladen.

Grüße,
 CK

[MichaelB]

Hallo,

Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.
Sind die Module eigentlich quasi mit einkompiliert oder werden sie on-demand geladen? Im
letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.

Weder, noch. Man kann sie statisch mit einkompilieren, man kann sie aber auch dynamisch
laden lassen. Allerdings werden die Module beim Startup geladen.

Also sind sie quasi einkompiliert.Das dachte ich mir schon.

Die fork() wird also immer von diesem (keine Resourcen belegenden) Vaterprozess gemacht

Falsch. Der Vaterprozess hat alle Module geladen, die Konfiguration geparsed, etc, pp.
Das ist halt die Frage ob der Apache wirklich alle Module beim Start lädt oder erst
on-demand. Den Apache-Quellcode habe ich dummerweise gerade nicht zur Hand. :-)

Er lädt sie direkt. Er *muss* sie sogar direkt laden. Jedes Modul kann
Konfigurations-Direktiven definieren. Die werden erst bekannt, wenn das Modul geladen ist.
Sind sie unbekannt, muss der Apache sie monieren.

Stimmt. Da ist was dran. Daran hatte ich nicht gedacht.

[...]
Ich habe aber behauptet, daß der Apache aber nicht so vorgeht sondern DB-Handles und
andere Resourcen immer von Kindprozessen des httpd geöffnet werden wärend der
Vaterprozess von dem die forks erzeugt werden natürlich keine offnen Handles hat.
Dementsprechend hat der Apache auch kein Problem mit Resourcen (wie DB-Handles) beim
forken.

Das hängt davon ab, wie das Modul, dass diese Ressourcen benutzt, programmiert ist.
Prinzipiell kann das Modul auch vor dem fork() bereits Ressourcen allokieren.

Prinzipiell natürlich schon. Aber in der Regel sollte man das nicht tun, um die schon besprochenen Schwierigkeiten beim forking zu vermeiden. Kann ja auch Fälle geben, wo dass Sinn macht. Da muss man natürlich immer abwägen.

Alles in Hinblick auf die Ausgangsdiskussion in der es darum ging ob sich ein dedizierter
Apache lohnt (weil beim forken zuviel Overhead entsteht) oder nicht. Und ich war eben
der Meinung so groß ist der Resourcenverbrauch nicht als das sich ein abgespeckter Apache
lohnt.

Das tut es in jedem Fall. a) wegen des gerigeren Aufwands beim fork()
und b) wegen des
geringeren Speicherverbrauchs.

Um es nochmal zu wiederholen: Bei dem Ausgangspunkt der Diskussion ging es darum auf ein und der selben Maschine zwei Apaches laufen zu lassen. Ein abgespeckten für statische Seiten der dann ggf. die Anfragen mit Skripten an den zweiten Apache (mit PHP, Datenbank usw.) weiterreicht. Und ich habe da so meine Zweifel, ob sich das wirklich lohnt vom Resourcenverbrauch und der Geschwindigkeit.
(und wenn schon, dann würde ich vor dem "dicken" Apache eher ein Squid setzen als ein abgespeckten zweiten Apache)

Mehr Klarheit würde bringen, wenn man wüßte ob Module on-demand geladen werden oder nicht.
Das sie als eigene Dateien vorliegen spricht dafür. Die Art wie sich eingebunden werden
dagegen. Wie ist das Ganze denn nun?

Der Apache-Startup läuft in drei Phasen:

Phase 1: grobes durchscannen der Konfigurations-Datei(en), so dass erkannt werden kann,
         welche Module geladen werden sollen.
Phase 2: Laden der Module und Handshaking mit ihnen (bekanntmachen der
         Konfigurations-Direktiven, Registrieren, etc, pp).
Phase 3: Genaues parsen der Konfigurations-Datei(en).

Alles klar.

Die Module bleiben geladen solange der Apache läuft und werden kein zweites mal geladen.

Das sie kein zweites Mal geladen werden ist ja eigentlich auch logisch. Das Thema Codesharing hatten wir ja schon.

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Wie auch immer, es lohnt sich trotzdem, den Apachen abzuspecken, da auch der Speicher der
Module mitkopiert werden muss. Auch wenn das on demand passiert, es muss geschehen.
Sind die Module eigentlich quasi mit einkompiliert oder werden sie on-demand geladen? Im
letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.

Weder, noch. Man kann sie statisch mit einkompilieren, man kann sie aber auch dynamisch
laden lassen. Allerdings werden die Module beim Startup geladen.
Also sind sie quasi einkompiliert.Das dachte ich mir schon.

Nene. Das macht schon einen Unterschied.

[...]
Ich habe aber behauptet, daß der Apache aber nicht so vorgeht sondern DB-Handles und
andere Resourcen immer von Kindprozessen des httpd geöffnet werden wärend der
Vaterprozess von dem die forks erzeugt werden natürlich keine offnen Handles hat.
Dementsprechend hat der Apache auch kein Problem mit Resourcen (wie DB-Handles) beim
forken.

Das hängt davon ab, wie das Modul, dass diese Ressourcen benutzt, programmiert ist.
Prinzipiell kann das Modul auch vor dem fork() bereits Ressourcen allokieren.
Prinzipiell natürlich schon. Aber in der Regel sollte man das nicht tun, um die schon
besprochenen Schwierigkeiten beim forking zu vermeiden.

Sag das nicht mir ;-) Ich habe es ja dir erklärt *g*

Kann ja auch Fälle geben, wo dass Sinn macht. Da muss man natürlich immer abwägen.

Das dürfte eigentlich immer in 'undefined behavior' enden...

Alles in Hinblick auf die Ausgangsdiskussion in der es darum ging ob sich ein dedizierter
Apache lohnt (weil beim forken zuviel Overhead entsteht) oder nicht. Und ich war eben
der Meinung so groß ist der Resourcenverbrauch nicht als das sich ein abgespeckter Apache
lohnt.

Das tut es in jedem Fall. a) wegen des gerigeren Aufwands beim fork()
und b) wegen des geringeren Speicherverbrauchs.
Um es nochmal zu wiederholen: Bei dem Ausgangspunkt der Diskussion ging es darum auf
ein und der selben Maschine zwei Apaches laufen zu lassen. Ein abgespeckten für
statische Seiten der dann ggf. die Anfragen mit Skripten an den zweiten
Apache (mit PHP, Datenbank usw.) weiterreicht. Und ich habe da so meine Zweifel, ob
sich das wirklich lohnt vom Resourcenverbrauch und der Geschwindigkeit.

Prinzipiell durchaus, wie gesagt. Das wurde durch Benchmarks ja durchaus auch schon
bewiesen. Nein, ich habe leider gerade keinen Link parat.

Grüße,
 CK

[MichaelB]

Hallo CK,

Weder, noch. Man kann sie statisch mit einkompilieren, man kann sie aber auch dynamisch
laden lassen. Allerdings werden die Module beim Startup geladen.
Also sind sie quasi einkompiliert.Das dachte ich mir schon.
Nene. Das macht schon einen Unterschied.

Aber letzlich kein bedeutenden. Oder gibt es irgendwelche Vorteile/Nachteile Module statisch/dynamisch  einzubinden?

Kann ja auch Fälle geben, wo dass Sinn macht. Da muss man natürlich immer abwägen.
Das dürfte eigentlich immer in 'undefined behavior' enden...

Ups ... warum das denn?

Um es nochmal zu wiederholen: Bei dem Ausgangspunkt der Diskussion ging es darum auf
ein und der selben Maschine zwei Apaches laufen zu lassen. Ein abgespeckten für
statische Seiten der dann ggf. die Anfragen mit Skripten an den zweiten
Apache (mit PHP, Datenbank usw.) weiterreicht. Und ich habe da so meine Zweifel, ob
sich das wirklich lohnt vom Resourcenverbrauch und der Geschwindigkeit.
Prinzipiell durchaus, wie gesagt. Das wurde durch Benchmarks ja durchaus auch schon
bewiesen. Nein, ich habe leider gerade keinen Link parat.

Aber der Overhead um einen zweiten eigenen Apache laufen zu lassen dürfte auch nicht ganz ohne sein. Wahrscheinlich kommt es (wie so oft) auf die Situation an.

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Weder, noch. Man kann sie statisch mit einkompilieren, man kann sie aber auch
dynamisch laden lassen. Allerdings werden die Module beim Startup geladen.
Also sind sie quasi einkompiliert.Das dachte ich mir schon.
Nene. Das macht schon einen Unterschied.
Aber letzlich kein bedeutenden. Oder gibt es irgendwelche Vorteile/Nachteile Module
statisch/dynamisch  einzubinden?

Jo. Ich muss nicht mehr bei jedem Modul den Apache neu kompilieren.

Kann ja auch Fälle geben, wo dass Sinn macht. Da muss man natürlich immer abwägen.
Das dürfte eigentlich immer in 'undefined behavior' enden...
Ups ... warum das denn?

Sockets oder Datenbankverbindungen oder so sind nicht dafür ausgelegt, durch fork()
dupliziert zu werden. Du hast dann zweimal das identische Handle, der gegenüberliegende
Prozess merkt gar nicht, dass jetzt jemand anderes mit einem redet. Das gibt
Synchronisationsprobleme. Prozess 1 stellt eine Anfrage, Prozess 2 stellt sie eine
Nanosekunde später, beim Kommunikationsparter kommt heilloses Chaos an.

Grüße,
 CK

[MichaelB]

Hallo CK,

Weder, noch. Man kann sie statisch mit einkompilieren, man kann sie aber auch
dynamisch laden lassen. Allerdings werden die Module beim Startup geladen.
Also sind sie quasi einkompiliert.Das dachte ich mir schon.
Nene. Das macht schon einen Unterschied.
Aber letzlich kein bedeutenden. Oder gibt es irgendwelche Vorteile/Nachteile Module
statisch/dynamisch  einzubinden?

Jo. Ich muss nicht mehr bei jedem Modul den Apache neu kompilieren.

Ok. Das ist klar. Ich meinte auch mehr was sonst noch so für Nachteile/Vorteile hat (z.B. laufzeittechnisch).

Kann ja auch Fälle geben, wo dass Sinn macht. Da muss man natürlich immer abwägen.
Das dürfte eigentlich immer in 'undefined behavior' enden...
Ups ... warum das denn?

Sockets oder Datenbankverbindungen oder so sind nicht dafür ausgelegt, durch fork()
dupliziert zu werden. Du hast dann zweimal das identische Handle, der gegenüberliegende
Prozess merkt gar nicht, dass jetzt jemand anderes mit einem redet. Das gibt
Synchronisationsprobleme. Prozess 1 stellt eine Anfrage, Prozess 2 stellt sie eine
Nanosekunde später, beim Kommunikationsparter kommt heilloses Chaos an.

Das ist mir schon klar. Aber solange es nicht zu Konflikten kommt, sollte das doch erstmal generell kein Problem darstellen. Und darum ging es mir.
Evtuelle Syncronisationen könnte man ja auch über andere Wege sicherstellen. Insgesamt kein sauberes Verfahren und macht niemand wahrscheinlich so, aber doch theoretisch machbar,

Gruß
   MichaelB

[Andreas Korthaus]

Hallo Michael!

Aber letzlich kein bedeutenden. Oder gibt es irgendwelche Vorteile/Nachteile Module
statisch/dynamisch  einzubinden?

Jo. Ich muss nicht mehr bei jedem Modul den Apache neu kompilieren.
Ok. Das ist klar. Ich meinte auch mehr was sonst noch so für Nachteile/Vorteile hat (z.B. laufzeittechnisch).

Vielleicht hilft Dir: http://httpd.apache.org/docs-2.0/dso.html#advantages

und vielleicht auch: http://httpd.apache.org/docs-2.0/misc/perf-tuning.html

Grüße
Andreas

[Andreas Korthaus]

Hallo!

Im
letzteren Fall würde durch zusätzliche Module beim forken kein Overhead entstehen.

Das ist aufgrund der Architektur des Apachen, sowohl beim prefork-mpm(http://httpd.apache.org/docs-2.0/mod/prefork.html) als auch beim worker-mpm(hybrid, multi-thread + multi-process... : [link:http://httpd.apache.org/docs-2.0/mod/worker.html) nicht sooo ausschlaggebend. Der Apache versucht immer einen Pool an freien Child-Prozessen zu haben, und immer wenn das zu wenig werden startet er vorsorglich neue Prozesse im Hintergrund. Genauso beendet er Prozesse, wenn zu viele nix zu tun haben. Das heißt, vom Forken bekommt man eigentlich nichts mit, weil das schon vorher geschieht. Wenn auf einmal zu viele Requests auf einmal eingehen, wird nicht wild geforkt, sondern nur 1 mal pro Sekunde 1 Prozess, nächste Sekunde 2, nächste 4... bis 32. Aber eine Belastung wo sowas nötig ist kommt in der Realität eigentlich nicht vor. Der Apache versucht nach Möglichkeit nichts an der Anzahl der Prozessen zu ändern.

Nein, mir geht es nicht darum, sondern es geht mir vor allem um die Größe und Laufzeit der Prozesse. Sag mal Du hast 512 MB RAM, und noch ein paar andere Dinge laufen, vielleicht noch 400 MB für den Apachen. Wenn Du jetzt in PHP den  Oracle Client verwendest, bringt es ein Apache-Prozess auf satte 20 MB(angeblich). Das heißt, es passen genau 20 Apache-Prozesse in den RAM, und das ist nicht wirklich viel. Verwendest Du jetzt allerdings 2 Webserver-Instanzen, und die andere Prozesse haben lediglich 3 MB, kannst Du den RAM aufteilen, jeder bekommt 200 MB, das heißt 10 Prozesse mit PHP(+Oracle-Client), und 70 Prozesse für statische Inhalte passen in den RAM. _Das_ ist der Hauptgedanke von mir gewesen.

Alles in Hinblick auf die Ausgangsdiskussion in der es darum ging ob sich ein dedizierter
Apache lohnt (weil beim forken zuviel Overhead entsteht) oder nicht.

Habe ich das jemals als Begründung angeführt?

Und ich war eben
der Meinung so groß ist der Resourcenverbrauch nicht als das sich ein abgespeckter Apache
lohnt.

Och, wenn Du komplexe Scripte/Module hast ist es möglicherweise über eine DSL-Leitung kein Problem den Server in Bedrängnis zu bringen!

(und wenn schon, dann würde ich vor dem "dicken" Apache eher ein Squid setzen als ein abgespeckten zweiten Apache)

Ja, wenn das denn mit SSL so einfach wäre ;-)

Grüße
Andreas

[Eternius]

Hallo,

mod_php oder mod_cgi.
sämtliche unnütze dienste abschalten, mehr ram.

gruss

[powtac]

mod_php oder mod_cgi.

php4_module benütze ich schon.

sämtliche unnütze dienste abschalten, mehr ram.

Also ich kenne mich nicht so gut aus, welche Dienste brauche ich auf keinen Fall. SSL z.B. habe ich schon entkommentiert in der httpd.conf.

[der implementierer]

Hallo,

mod_php oder mod_cgi.
sämtliche unnütze dienste abschalten, mehr ram.

wusste gar nicht das php und cgi unnütz ist !?

mfg

[Eternius]

Hallo

Hallo,

mod_php oder mod_cgi.
sämtliche unnütze dienste abschalten, mehr ram.

wusste gar nicht das php und cgi unnütz ist !?

häh?

gruss

[Christoph Schnauß]

hi,

wusste gar nicht das php und cgi unnütz ist

Das sind sie auch nicht. Aber die Module sind es  -  jedenfalls unter Win98. PHP und CGI werden anders angesprochen, man braucht die Module nicht dazu.

Grüße aus Berlin

Christoph S.

[powtac]

Folgende Dienste - Dynamic Shared Object (DSO) habe ich noch laufen.
Welche davon kann ich abschalten?

LoadModule access_module modules/mod_access.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_module modules/mod_auth.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule imap_module modules/mod_imap.so
LoadModule include_module modules/mod_include.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule userdir_module modules/mod_userdir.so

PHP:

LoadModule php4_module c:\php4apache2.dll

[Eternius]

Hallo,

ah jetzt verstehe ich, deine verständnis von diensten und meins,
ich meinte jetzt aber die "dienste" von win98, dass heisst nur programme starten, die du auch wirklich brauchst.

aber deine module.conf kannst du auch ruhig abspecken.
welche du da rauschmeisst musst du selber rausfinden, dass kommt nämlich auf deine konfiguration und skripte etc an.

gruss

[powtac]

Das "Problem" ist, bei Win98 gibt es soetwas wie Dienste bei Win2000o.ä. nicht. Habe aber alles unnötiges abgestellt.

Was meinst Du mit module.conf?

[Eternius]

sorry

httpd.conf

gruss

[Christoph Schnauß]

hallo,

sorry

Warum denn? So dumm ist die Idee gar nicht, die Modul-Liste in eine extra modules.conf auszulagern und die dann wieder in der httpd.conf per "include" aufzurufen. Ich mache das gerne so, es trägt erheblich zur Übersichtlichkeit bei  -  und wenn ich es richtig in Erinnerung habe, wird es zum Beispiel bei der SuSE 9.0 ebenfalls auf diesem Weg gemacht.

Grüße aus Berlin

Christoph S.

[Eternius]

hallo,

danke ;-)

wird es zum Beispiel bei der SuSE 9.0 ebenfalls auf diesem Weg gemacht.

gruss

[Christoph Schnauß]

hi,

ich meinte jetzt aber die "dienste" von win98

In Windows 98 gibt es das Konzept der "Dienste" noch gar nicht, es ist unsinnig, darüber zu philosophieren.
Man kann sich eine Vergleichskonstruktion mit sehr viel Mühe implementieren, aber das bleibt Stückwerk. Das einzige, was hilft, ist, ein deutlich aktuelleres Betriebssystem zu installieren und eventuell die Hardware auch etwas zu modernisieren.

Grüße aus Berlin

Christoph S.

[wahsaga]

hi,

Folgende Dienste - Dynamic Shared Object (DSO) habe ich noch laufen.
Welche davon kann ich abschalten?

die, die du nicht brauchst.
schau in der apache-doku nach, was die machen, und ob du sie brauchst.
wenn du nicht sicher bist, werfe einen nach dem anderen raus, und wenn was nicht mehr geht, na ja, dann nimmste halt den letzten wieder rein ;-)

gruss,
wahsaga

[powtac]

OK, danke!

Was ist mit:

Timeout 100
KeepAlive On
MaxKeepAliveRequests 50
KeepAliveTimeout 15

Bitte bedenken, ich bin ein einzelner Anwender, der maximal 3 Browserfenster offen hat...

[Andreas Korthaus]

Hallo!

ich habe Apache Version 2. und PHP 4.3 local auf Win 98 laufen, doch teilweise brauchen meine Sript ziemlich lange um ausgeführt zu werden.

Gehen statische Inhalte denn viel schneller?
Sind alle Scripte langsam?
Wie sieht die Systemlast aus wenn es langsam wird? Wer verbraucht viel CPU, RAM...
Was ist das für ein Rechner?(CPU, RAM...)

Wie kann ich Apache tunen um die Scripte laufen zu lasen?

Benutzt Du den Apachen nur auf localhost?

Windows 98 ist beim besten Willen kein Server-Betriebssystem, Du solltest wenigstens sowas wie Windows NT, besser 2000, XP oder 2003 nehmen. Lies mal http://httpd.apache.org/docs-2.0/platform/windows.html, da wird einiges dazu gesagt. Die Unterstützung von Windows 98 ist höchstens als "experimentell" zu bezeichnen. Es kann gut sein dass es da irgendein Problem gibt.

Grüße
Andreas

[Christian Kruse]

Hallo powtac,

ich habe Apache Version 2. und PHP 4.3 local auf Win 98 laufen, doch teilweise brauchen
meine Sript ziemlich lange um ausgeführt zu werden. Wie kann ich Apache tunen um die Scripte
laufen zu lasen?

Vielleicht ist

http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html

interessant für dich.

Grüße,
 CK

[Christoph Schnauß]

hehe CK,

http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html

Seit wann gibts denn das? Ich lese ziemlich regelmäßig die "news" hier, aber da wars nirgends bisher drin. Allerdings schaue ich nicht jeden Tag bei http://aktuell.de.selfhtml.org/artikel/server vorbei. Und btw: könnte man bei den Artikeln nicht das Datum der Veröffentlichung mit dazuschreiben?

Grüße aus Berlin

Christoph S.

[Christian Kruse]

Hallo Christoph,

http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html

Seit wann gibts denn das?

Seit heute.

Ich lese ziemlich regelmäßig die "news" hier, aber da wars nirgends bisher drin.

Ist auch noch nicht ver-news-t worden.

Grüße,
 CK

[Christoph Schnauß]

hi,

http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html
Seit wann gibts denn das?
Seit heute.

Ahso. Dann konnte ich das ja noch nicht kennen. Bin erstmal hindurchgebraust und finde die Farben deiner Konsolen-Screenshots ganz fürchterlich schröcklich *g*
Es will mir auch scheinen, als könnte deine Liste der "essentiellen" Module noch verkürzt werden.

Ist auch noch nicht ver-news-t worden.

Das heißt, alle, die dein posting zufällig gefunden haben, sind gewisermaßen vorinformiert und damit privilegiert. Wow. Aber ich nehme an, daß der Artikel demnächst ver-news-t werden wird, und dann kann ich mich ja zurücklehnen und sagen: weiß ich doch schon alles ;-)

Grüße aus Berlin

Christoph S.

[Matti Maekitalo]

use Mosche;

Das heißt, alle, die dein posting zufällig gefunden haben, sind gewisermaßen vorinformiert und damit privilegiert. Wow. Aber ich nehme an, daß der Artikel demnächst ver-news-t werden wird, und dann kann ich mich ja zurücklehnen und sagen: weiß ich doch schon alles ;-)

Ja und. Ich habe damals (vor langer, langer Zeit) den Artikel Original im Limux-Magazin gelesen. :-) *Ich* bin privilegiert. :-)

use Tschoe qw(Matti);

[Thomas W.]

Hallo,

Ahso. Dann konnte ich das ja noch nicht kennen.

http://forum.de.selfhtml.org/archiv/2003/12/66198/

Gruss
Thomas