nicht angemeldet
und Apache2 schon produktiv einsetzen?
Hallo!
Ich überlege gerade ob ich Apache1 oder 2 als webserver in einer produktiven Umgebung einsetzen soll.
Apache2 an sich ist ja inzwischen durchaus stabil, aber auch in Kombination mit PHP? Bei der Installation von PHP 4.3 wurde nochmal deutlich drauf hingewiesen dass das PHP-Modul für Apache2 noch experimentell ist und nicht produktiv eingesetzt werden sollte. Wie seht Ihr das? Ich hatte noch nie Probleme beim testen - was ist Euch bekannt?
Was hätte Apache2 überhaupt für Vorteile gegenüber 1? Soll meines Wissens schneller sein, und flexibler in der Rechtevergabe, sonst noch was? Lohnt sich das Risiko? Wie kann ich das Risiko abschätzen, und wie groß ist der Geschwindigkeitsvorteil dagegen?
Viele Grüße
Andreas
-
hallo Andreas,
Ich überlege gerade ob ich Apache1 oder 2 als webserver in einer produktiven Umgebung einsetzen soll.
Das hängt möglicherweise davon ab, wie "produktiv" deine Umgebung sein soll, und was da alles stabil laufen muß
Apache2 an sich ist ja inzwischen durchaus stabil, aber auch in Kombination mit PHP? Bei der Installation von PHP 4.3 wurde nochmal deutlich drauf hingewiesen dass das PHP-Modul für Apache2 noch experimentell ist und nicht produktiv eingesetzt werden sollte.
Wenn alle Softwarehersteller derart vorsichtig mit ihren Hinweisen umgehen wollten, wärs zwar schön, aber wir hätten dann wohl nur noch beta-Software auf den Rechnern ...
Wie seht Ihr das? Ich hatte noch nie Probleme beim testen - was ist Euch bekannt?
Ich habe die Kombination Apache 2.0.43 und PHP 4.3.0 inzwischen seit Wochen sowohl mit WinXP wie auch mit FreeBSD laufen und bisher überhaupt keine Probleme bemerkt. Allerdings kann ich nicht behaupten, daß ich _alles_ ausgetestet hätte
Was hätte Apache2 überhaupt für Vorteile gegenüber 1?
GRößere Übersichtlichkeit, größere Flexibilität, konsequenter durchgehaltenes Modul-Konzept. Für Details die Apache-Doku fragen *g*
Lohnt sich das Risiko?
Aus meiner Sicht lohnt es sich inzwischen. Aber wie gesagt, _alles_ habe ich gewiß noch nicht durchgespielt
Grüße aus Berlin
Christoph S.
-
Hallo Christoph!
Das hängt möglicherweise davon ab, wie "produktiv" deine Umgebung sein soll, und was da alles stabil laufen muß
Es ist ein modulares, für meine Verhältnisse recht komplexes PHP-Projekt, auf viele Dateien verteilt(viele includes, viele Klassen, einige PEAR-Module, Smarty-Templates...), und das ganze läuft mit einem Datenbank-Server, wahrscheinlich postgres, vielleicht auch mysql, vielleicht auch die RedHat-eigene, Postgres-Version, mal schaun. Jedenfalls ist das keine einfache Präsentations-Webseite, sondern eine Web-Anwendung(Extranet...).
Als OS wird entweder RedHat Linux 7.3 oder 8.0 eingesetzt.Datensicherheit und Stabilität sind die mit Abstand wichtigsten
Kriterien.Dem entsprechend wird die ganze Software entwickelt(DB-Transaktionen, ausgeklügelte Error-Routinen...). Unter diesem Gesichtspunkt, und unter dem das der Webserver nicht stark belastet werden wird, vielleicht maximal 10-20 Anfragen(aber die gehen dann auch an komplexe PHP-Scripte) pro Sekunde(mit sehr vielen Reservern), sollte man wohl doch eher auf den alten 1er setzen - sicher ist sicher, oder?
Leider ist sowas sehr schwierig zu simulieren.Gibt es Tests wie viel schneller der neue Apacher ist?
Mal eine Frage zur Performance. Es gibt ja grob 3 Möglichkeiten PHP zu installieren:
1. Als CGI-Version
2. Als Apache-Modul
3. ebenfalls als Apache-Modul, aber dabei komplett in den httpd einkompiliert.Was haltet Ihr von diesen Methoden, untern den Gesichtspunkten Performance und Stabilität? Die Unterschiede in der Veränderbarkeit sind hier wohl eindeutig.
Und wie wäre es jetzt noch das Datenbank-Modul von PHP mit einzukompilieren? Was haltet Ihr von sowas?
Viele Grüße
Andreas-
n'abends ;-)
Das hängt möglicherweise davon ab, wie "produktiv" deine Umgebung sein soll, und was da alles stabil laufen muß
Es ist ein modulares, für meine Verhältnisse recht komplexes PHP-Projekt, [...] eine Web-Anwendung(Extranet...).Hm. Also trotz der Komplexität der PHP-Konstruktion nix, was irgendwelche "besonderen Module" im Apache erfordern würde, und für die PHP-spezifischen Geschichten in deinem Projekt ist dann eben auch PHP zuständig - da kann die 4.3 nun einmal manches besser und/oder einiges mehr als die Vorgänger. _Diese_ Anforderungen sprechen noch nicht dagegen, es auch mal mit Apache 2 zu versuchen.
BTW: ist denn eigentlich auch bei PHP 4.3 irgendwas "verlorengegangen", was vorherige Versionen konnten ?Der Umgang mit der Datenbank ist Sache von PHP. Was postgres angeht, weiß ich nicht sehr viel, ich habe mich damit nie so recht anfreunden können, mySQL ist mir vertrauter
Als OS wird entweder RedHat Linux 7.3 oder 8.0 eingesetzt.
Mit Verlaub: mit Ausnahme der SuSE sind mir bei den anderen Distributionen die Versionsangaben relativ wurscht. Nach einer Weile, wenn du dir deinen Kernel korrekt für deine Anforderungen gebacken hast und die Software auch sonst dazu "stimmt", ist es eh kein "RedHat x.x" mehr, sondern ein "RedHat Korthaus" *g*. Die Sourcen hältst du ja wohl aktuell ...
Datensicherheit und Stabilität sind die mit Abstand wichtigsten
Kriterien.Da hab ich bisher zwischen Debian 3.0 mit Apache 1.3.x und FreeBSD mit Apache 2.0.43 keine Unterschiede feststellen können, was heißt: Sicherheits- oder Stabilitätseinbußen waren nicht zu bemerken. Bei Apache 2.0.x kleiner als 2.0.43 gab es manchmal unerklärliche Errors, mit 2.0.43 nicht mehr
Dem entsprechend wird die ganze Software entwickelt(DB-Transaktionen, ausgeklügelte Error-Routinen...).
Das sollte die Kombination aus Apache 2.0.43 und PHP 4.3 bewältigen können
Unter diesem Gesichtspunkt [...] sollte man wohl doch eher auf den alten 1er setzen - sicher ist sicher, oder?
Vorsicht ist durchaus angebracht. Aber was du bisher genannt hast, ist nach _meinem_ bisherigen Kenntnisstand kein Gegenargument gegen ein Upgrade
Leider ist sowas sehr schwierig zu simulieren.
Hängt von deiner "Hardware-Umgebung" ab ;-) Ichj befinde mich da im Schlaraffenland, weil ich in der Bildungseinrichtung, in der ich gelegentlich irgendwelchen Leuten den Unterschied zwischen Maus und Tastatur klarmachen darf (naja, ab und an auch ein bißchen mehr) immer irgendein "Netz" mit einem Dutzend (oder mehr) überwiegend sehr moderner Rechner zur Verfügung habe - meine "Schüler" brauchen nicht immer alles mitzukriegen (können sie oft auch nicht), was ich da durchspiele
Gibt es Tests wie viel schneller der neue Apacher ist?
Vielleicht weiß Michael Schröpl was dazu. Mir ist keiner bekannt, der verläßliche Werte liefert
- Als CGI-Version
- Als Apache-Modul
- ebenfalls als Apache-Modul, aber dabei komplett in den httpd einkompiliert.
Was haltet Ihr von diesen Methoden?
Aus meiner Sicht plattformabhängig. Mit WinXP würde ich ziemlich grundsätzlich die "CGI-Variante" empfehlen, mit LINUX bzw. *BSD dagegen für Nummer 3 (komplett kompiliertes Modul) plädieren. Das hat einfach damit zu tun, daß es mit LINUX oder *BSD relativ leicht ist, aus den Sourcen heraus auch ein "großes" Softwarepaket bedarfsgerecht zu kompilieren, während das unter Windows immer ein Risiko ist - und auch noch teuer, weil man sich den entsprechenden Compiler ja erst noch besorgen muß. Und es gibt auch ein paar Unterschiede in den Bibliotheken, die die Compiler mitbringen
Und wie wäre es jetzt noch das Datenbank-Modul von PHP mit einzukompilieren? Was haltet Ihr von sowas?
Ausprobieren und Ergebnisprotokoll herschreiben ;-)
Grüße aus Berlin
Christoph S.
-
Hallo Christoph!
Hm. Also trotz der Komplexität der PHP-Konstruktion nix, was irgendwelche "besonderen Module" im Apache erfordern würde, und für die PHP-spezifischen Geschichten in deinem Projekt ist dann eben auch PHP zuständig - da kann die 4.3 nun einmal manches besser und/oder einiges mehr als die Vorgänger. _Diese_ Anforderungen sprechen noch nicht dagegen, es auch mal mit Apache 2 zu versuchen.
_Was_ spräche denn dagegen? Ich setze PHP als Apache(2)-Modul ein, da brauche und gerade dieses soll noch experimentell sein! Was hat das mit anderen Apache-Modulen zu tun? Der Apache an sich ist sicher sehr stabil inzwischen, es geht nur um das PHP-Modul!
BTW: ist denn eigentlich auch bei PHP 4.3 irgendwas "verlorengegangen", was vorherige Versionen konnten ?
Ja, aber nichts wichtiges:
http://www.php.net/ChangeLog-4.php
http://www.php.net/release_4_3_0.phpAch ja, kennst Du schon: http://snaps.php.net/php5-latest.tar.gz
Habs mir mal angesehen, aber noch nichts von den großen Neuerungen gesehen :-(
Der Umgang mit der Datenbank ist Sache von PHP. Was postgres angeht, weiß ich nicht sehr viel, ich habe mich damit nie so recht anfreunden können, mySQL ist mir vertrauter
mir auch, aber ich habe inzwischen mehr gutes pber postgres gehört als über mysql. Steht aber noch nicht fest.
Mit Verlaub: mit Ausnahme der SuSE sind mir bei den anderen Distributionen die Versionsangaben relativ wurscht. Nach einer Weile, wenn du dir deinen Kernel korrekt für deine Anforderungen gebacken hast und die Software auch sonst dazu "stimmt", ist es eh kein "RedHat x.x" mehr, sondern ein "RedHat Korthaus" *g*. Die Sourcen hältst du ja wohl aktuell ...
Normalerweise schon, ich kenne mich nicht aus wie Du weißt, aber meines Wissens verwendet RH8 einen neue Version des GCC Compilers oder sowas, der jedenfalls nicht mehr voll kompatibel zu alten Sourcen ist.
"Akuell" kann ich meine Programme nicht wirklich nennen, ich verwende weitgehend die von Updates Redhat angebotenen Updates, meistens Sicherheits-Löscher stopfen, die sind aber meist schon etwas älter. Das erste mal habe ich jetzt PHP 4.3 kompiliert, das hat zwar geklappt, aber ich habe es nicht mit JPEG und PNG-Support hinbekommen. Bin halt noch ein Linux-Anfänger :-)Da hab ich bisher zwischen Debian 3.0 mit Apache 1.3.x und FreeBSD mit Apache 2.0.43 keine Unterschiede feststellen können, was heißt: Sicherheits- oder Stabilitätseinbußen waren nicht zu bemerken. Bei Apache 2.0.x kleiner als 2.0.43 gab es manchmal unerklärliche Errors, mit 2.0.43 nicht mehr
Wie hast Du das denn eingesetzt? Nur ein paar private Tests, oder einige "live"-Seiten?
Das sollte die Kombination aus Apache 2.0.43 und PHP 4.3 bewältigen können
Apache hat ja erstmal nichts damit zu tun, da hast Du schon Recht, und PHP 4.3 verwende ich auf alle Fälle. Ach ja, wo wir schon mal dabei sind - die Zend Engine2 ist wohl noch experimentell, oder? Vielleicht gucke ich mit auch mal immer die aktuellen stabilen snaps von snaps.php.net an, meines wissens sind das meist Bug-Fixes, und vielleicht ja auch was bzgl. Apache2.
Unter diesem Gesichtspunkt [...] sollte man wohl doch eher auf den alten 1er setzen - sicher ist sicher, oder?
Vorsicht ist durchaus angebracht. Aber was du bisher genannt hast, ist nach _meinem_ bisherigen Kenntnisstand kein Gegenargument gegen ein UpgradeWas wäre den gefährlich? Ich setze auch eine HTTP-Authentifizierung über Apache ein, Header- Weiterleitungen, mails... alles was halt so dazu gehört, wo siehst Du potentielle Gefahren?
Leider ist sowas sehr schwierig zu simulieren.
Hängt von deiner "Hardware-Umgebung" ab ;-) Ich befinde mich da im Schlaraffenland, weil ich in der Bildungseinrichtung, in der ich gelegentlich irgendwelchen Leuten den Unterschied zwischen Maus und Tastatur klarmachen darf (naja, ab und an auch ein bißchen mehr) immer irgendein "Netz" mit einem Dutzend (oder mehr) überwiegend sehr moderner Rechner zur Verfügung habe - meine "Schüler" brauchen nicht immer alles mitzukriegen (können sie oft auch nicht), was ich da durchspieleIch habe leider nur ein kleines LAN mit 5 Rechnern zu Verfügung, da ist das schon begrenzt.
Gibt es Tests wie viel schneller der neue Apacher ist?
Vielleicht weiß Michael Schröpl was dazu. Mir ist keiner bekannt, der verläßliche Werte liefertWürde mich sehr interessieren!
- Als CGI-Version
- Als Apache-Modul
- ebenfalls als Apache-Modul, aber dabei komplett in den httpd einkompiliert.
Was haltet Ihr von diesen Methoden?
Aus meiner Sicht plattformabhängig. Mit WinXP würde ich ziemlich grundsätzlich die "CGI-Variante" empfehlen, mit LINUX bzw. *BSD dagegen für Nummer 3 (komplett kompiliertes Modul) plädieren. Das hat einfach damit zu tun, daß es mit LINUX oder *BSD relativ leicht ist, aus den Sourcen heraus auch ein "großes" Softwarepaket bedarfsgerecht zu kompilieren,
relativ leicht ist relativ relativ ;-) Ich habe da noch so meine Probleme. Außerdem habe ich nur Apache 2.0.37, ich sollte vielleicht auf den aktuellen 2.0.43 updaten. Nochwas, IMHO wird in der PHP-Installation empfohlen, den Apachen mit prefork zu kompilieren, also damit werden doch die Vorteile die man sich hiervon versprechen könnte soweiso zunichte gemacht, oder?
Und wie wäre es jetzt noch das Datenbank-Modul von PHP mit einzukompilieren? Was haltet Ihr von sowas?
Ausprobieren und Ergebnisprotokoll herschreiben ;-)Langsam, langsam! Ich bin erstmal froh wenn PHP 4.3 überhaupt komplett läuft.
Aber nochmal zum einkompilieren des Datenbank-Servers, muß das immer von Vorteil für die Performance sein? Ich meine, wenn ich komplett PHP und Postgres(ich glaube aber nur das PHP-Modul und nicht den dämon, oder?)http://www.php3.de/manual/de/install.apache.php, das hieße das PHP sehr schnell wird, da der Interpreter nicht immer geladen werden muß, aber hat das auch Auswirkungen auf die Datenbank? Der httpd inkl. PHP ist ja dann schnell verfügbar, der Datenbank-dämon eigentlich auch, trotzdem dauert der Aufbau der Datenbank-Verbindung von allem mit Abstand am längsten. Wie kann man auch das noch verkürzen?
Und noch ein anderer Ansatz: Da ich Apache2 dann ja sowieso nur mit "angezogener Handbremse" laufen lasse(prefork), ist es dann nicht besser einen PHP-Cache zu verwenden? Da gibts tolle Sachen, z.B. http://www.php-accelerator.co.uk/, les mal ein bisschen auf der Seite, angeblich 3-5 fache Beschleunigung der PHP-Scripte ohne Einfluss auf bestehende Scripte zuhaben, als Performance in Tests = Zend Cache, ich werde es mal probieren - funktioniert aber nur mit Apache 1.3. Aber ich denke mit sowas bin ich am Ende schneller _und_ sicherer als Apache2, oder?
Wird das ganez eigentlich langsamer, wenn ich einerseitz vieel Apache-Module installiert habe(von denen ich die meisten niemals brauche), und dasselbe mit PHP-Modulen? Icvh versteh das nicht ganz, das libphp.so also das Apche Modul welches ich kompiliert habe war 4 mal so fgroß als das originale von Redhat, obwohl ich nur halb so viele Konfigurationspartameter verwendet habe - wie kann das sein? Wie bekomme ich das auch so schön klein? Denn das ist wohl in jedem Fall besser!
Vielen Dank und viele Grüße
Andreas-
Holla!
Hatte das zwar kürzlich schonmal hier angesprochen, aber die Vorschläge von Michael habe ich damals leider nicht wirklich umsetzen können, da ich einfach noch nicht so weit bin, auch da ich die Installation eiens Programmes unter Linux noch nicht umfassend verstanden habe. Wie ich das bisher verstanden habe, werden mit configure und make Dateien erzeugt, aus denen make install danach die eigentliche Installation durchführt, wobei Installation nur heißt das dass die der Konfiguration entsprechend kompilierten Dateien an bestimmte Pfade kopiert werden, und nicht das irgendwelche conf-system-Dateien verändert werden, oder? Das heißt, wenn ich apache 2 installiert habe, ist das der Apache der in den Startup-Scripten steht, der ander, neu instalierte 1er Apache ist zwar da, läuft aber nicht. Und wenn muß ich erst den Apche 2 beenden, damit da keine 2 Programme auf Port 80 laufen könne(oder den Port ändern).
Wenn ich in meinem Home-Verzeichnis einen Apachen 1 und einen 2 entpacke, und von dort aus configure, make, make install verwende, überschreiben sich die Dateien dann gegenseitig? So ganz habe ich das leider noch nicht verstanden, auch nach lesen der Apache Insall-Doku, und selflinux.
Jetzt mal ganz unabhängig davon wie ich es später optimal machen kann. wie mache ich es so einfach wie möglich, so nah wie möglich an einer einzel-Version, das ich auch alles mögliche von Hand ändern muß, aber ich will erstmal due grundlage verstehen, bevor ich mich an die Vereinfachung für den Alltag mache!
Viele Grüße
AndreasPS: Beziehe mich hier auf Linux(Redhat 8)
-
Hi Andreas,
[...]
Du hast vollkommen Recht, dass sich mit den Apachen aus deiner Distri via make und install die Dateien gegenseitig wohl überschreiben werden. Ich habe es folgendermaßen gelöst:
1. Den Apachen 1.3.20 aus (meiner) Debian-Distri "normal" installiert.
2. Den 2.x-Apachen von http://www.apachefriends.org/lampp.html gezogen, in opt/lampp/ entpackt und auch der läuft (latürnicht auch gleichzeitig, wenn ich den Port ändere).Ich habe also zwei, von einander völlig unabhängige, Apachen am laufen. Wahlweise sogar mit dem gleichen DocumentRoot.
PS: Beziehe mich hier auf Linux(Redhat 8)
Ist relativ wurscht, der Lampp von Apachefriends läuft auf allen Linuxxen.
Fabian
-
Hallo Fabian!
Danke für den Tipp, nur will ich es jetzt um jeden Preis einmal von vorne bis hinten selber machen und dabei einmal komplett verstehen.
Folge Fragen habe ich dabei noch:
Wohin(welches Verzeichnis) entpackt man normalerweise/sinnvollerweise die Sourcen?
Beim make install werden ja dann die binaries wie httpd erstellt und an entsprechende Stelle kopiert. Wie mache ich das ganze manuell mit 2 httpd's? Ohne das der eine überschreiben wird?Grüße
Andreas-
hallo Andreas,
Wohin(welches Verzeichnis) entpackt man normalerweise/sinnvollerweise die Sourcen?
Das ist vollkommen wurscht. Wenn einmal der configure/make/make install-Lauf durch ist, liegen die "Fertigen" Bestandteiel da, wo sie hin sollen. Die Sourcen bzw. entpackten Dateien kannst du nach dem Kompilieren wieder löschen und dir dein *.tar.gz-Archic (oder welches Format du auch immer geholt hast) dort abspeichern, wo du dein eigenes "Archiv" hast
Beim make install werden ja dann die binaries wie httpd erstellt und an entsprechende Stelle kopiert. Wie mache ich das ganze manuell mit 2 httpd's?
Du schaust dir das configure-Script an. Oder gibst bei "configure" noch das entsprechende "PREFIX" vor, also einen Pfad. Wenn sich diese Pfade unterscheiden, sind zwei (oder mehr) Indianer unabhängig voneinander lauffähig. Du kannst sie sogar beide, wenns denn sein muß, mit einem entsprechenden Startscript bei Systemstart losmarschieren lassen, und es ist problemlos möglich, mehrere Apache-Versionen auf dasselbe Document-Root zugreifen zu lassen.
Michael hat irgendwo - leider finde ich das im Moment auch nicht mehr im Archiv - einen Vorschlag geäußert, der noch einen anderen Weg ging: er hat eine _zentrale_ httpd.conf, in der aber nix andres drinsteht als eine bzw. mehrere include-Anweisungen für unterschiedliche Apache-KonfigurationenOhne das der eine überschreiben wird?
Sie überschreiben einander nicht, wenn das mit "PREFIX" richtig gehandhabt wird. Es gibt dazu in der INSTALL ein paar kurze Hinweise
Grüße aus Berlin
Christoph S.
-
-
-
-
-