Apache und PHP optimal kompilieren?

[Odysseus]

Ich würde gerne ein paar Optimierungen an meinem Grundsystem vornehmen und frage mich daher, welche Optionen ich bei der Kompilierung von PHP und Apache brauche, und welche ich eigentlich rauswerfen kann.

Momentan sehen meine Configure Strings so aus:

PHP 4.4.0
./configure --prefix=/usr --datadir=/usr/share/php --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-_lib=lib64 --with-config-file-path=/etc --with-exec-dir=/usr/lib64/php/bin --disable-debug --enable-inline-optimization --enable-memory-limit --enable-magic-quotes --enable-safe-mode --enable-sigchild --disable-ctype --disable-cli --disable-ipv6 --with-mysql --with-mysql-sock=/var/lib/mysql/mysql.sock --with-ftp --with-zlib --with-libpng-dir=/usr/local --with-gd=/usr/local --with-jpeg-dir=/usr/local/lib --without-pear --with-openssl --with-apxs2=/usr/local/apache2/bin/apxs

APACHE 2.0.55
./configure --enable-auth-digest=shared --disable-actions --enable-logio --disable-asis --disable-imap --disable-userdir --enable-so --enable-ssl --enable-cgi=shared --disable-negotiation --enable-suexec=shared --with-suexec-caller=www-data --with-suexec-docroot=/home --with-suexec-logfile=/var/log/suexec.log --enable-deflate --enable-rewrite --prefix=/usr/local/apache2


Was sind die Minimalanforderungen für vBulletin, insbesondere bei PHP? Auf was konnte ich beim Apache eurer Meinung nach verzichten? Was kann man jeweils noch per disable-Option rauswerfen?

Meine Ideen bisher:

PHP -- weg mit: with-ftp, enable-sigchild (letzteres lapier ich nicht, was es tut)

Apache -- weg mit: enable-auch-digest, enable-logio, enable-cgi, das ganze suexec Zeug ... kapier eh nicht ganz, was das machen soll


Danke schon mal. :)


PS: Glaubt ihr, dass die Frage auf vB.com besser aufgehoben ist?

[Tomek]

Öhm, Gegenfrage: Wenn du davon keine Ahnung hast, warum willst du dann alles selbst kompilieren? Was erwartest du dir davon?

Wenn du die Pakete deiner Distribution verwendest, hast du deutlich weniger Arbeit bei der Installation und bei den nachträglichen Sicherheitsupdates.

[Odysseus]

Wer sagt, dass ich keine Ahnung habe? :)
Ich habe die Konfigs ja schon recht weit optimiert, aber womöglich findet jemand noch den einen oder anderen Tweak, den ich übersehen habe.

Auf die recht "überladene", weil universell einsetzbare PHP Version von SuSE verzichte ich dankend. ;)

[Tomek]

Wer sagt, dass ich keine Ahnung habe? :)
Ich habe die Konfigs ja schon recht weit optimiert, aber womöglich findet jemand noch den einen oder anderen Tweak, den ich übersehen habe. Das was du da machst, ist keine Optimierung, sondern lediglich eine Auswahl an Optionen.

Eine Optimierung wäre z.B. spezielle Compiler-Flags einzusetzen, ein anderes Thread-Modell zu wählen oder einen PHP-Beschleuniger zu installieren.

Auf die recht "überladene", weil universell einsetzbare PHP Version von SuSE verzichte ich dankend. ;) Die Version von SUSE Linux ist nicht überladen, wenn du es richtig konfigurierst. Die Distributionen bieten viele Funktionen an, die man aber nicht zwingend aktivieren muss. Bei Apache und PHP kannst du auch bei SUSE Linux genau auswählen, welche Apache-Module und PHP-Erweiterungen geladen werden sollen.

[ugr|dual]

ich empfehle php so zu lassen wie es ist und einen php-cache einzusetzen wie z.b. eaccelerator.

und bei apache das entsprechende modell zu wählen (hier z.b. mpm-prefork) und nur die module zu laden die auch gebraucht werden.

das ist einfach und tut den job.

[Odysseus]

@Tomek: Hm ... da hast du sicher Recht. Aber meinem Verständnis nach sollte eine Software, die gleich mit wenigen Modulen kompiliert worden ist, schneller sein als eine, bei der man einige Optionen während der Laufzeit weglässt. Immerhin entsteht beim Kompilieren ja ein Binary, der jedesmal geladen werden muss...

@ugr|dual: mpm-prefork ...ist das wirklich schon so weit erprobt? Ich hatte bisher immer darauf verzichtet. Bringt das einen niedrigen RAM Verbrauch ein?


ICh habe jetzt mal diesen eAccelerator installiert. Lange habe ich mich davor gescheut, denn in den Vergangenheit hatte ich keine besonders guten Erfahrungen mit Turck MMcache und früheren Versionen von eAccelerator gemacht: immer nach ein paar Tagen kan es zu scheinbar willkürlich auftretenden Server Freezes, die eindeutig auf diese Bytecode Caches zurückzuführen waren. Wunderte mich auch nicht, da ich ja immer gerne die aktuelle PHP Version einsetze, und das Zeug eben nicht so schnell getestet werden kann. (Seit gestern habe ich auch v4.4.1 drauf, z.B.)

Ich versuche es jetzt aber mal wieder mit eA. Scheint so weit auch hervorragend zu laufen! Mal sehen, wie das auf längere Zeit wird.


Besten Dank schon mal an euch beide.

[Tomek]

@Tomek: Hm ... da hast du sicher Recht. Aber meinem Verständnis nach sollte eine Software, die gleich mit wenigen Modulen kompiliert worden ist, schneller sein als eine, bei der man einige Optionen während der Laufzeit weglässt. Immerhin entsteht beim Kompilieren ja ein Binary, der jedesmal geladen werden muss...
Nein, das verstehst du falsch. Genau dafür machen die Distributoren doch den Aufwand mit den einzelnen Paketen. Es wird dir nichts bringen, außer einen Mehraufwand bei der Installation und bei späteren Updates.

@ugr|dual: mpm-prefork ...ist das wirklich schon so weit erprobt? Ich hatte bisher immer darauf verzichtet. Bringt das einen niedrigen RAM Verbrauch ein?
Das Prefork-Modell ist bereits das standardmässig eingesetzte Thread-Modell bei Apache2.

Informationen zu den einzelnen Thread-Modellen findest du hier (http://httpd.apache.org/docs/2.0/de/mpm.html).

[ugr|dual]

ICh habe jetzt mal diesen eAccelerator installiert. Lange habe ich mich davor gescheut, denn in den Vergangenheit hatte ich keine besonders guten Erfahrungen mit Turck MMcache und früheren Versionen von eAccelerator gemacht: immer nach ein paar Tagen kan es zu scheinbar willkürlich auftretenden Server Freezes, die eindeutig auf diese Bytecode Caches zurückzuführen waren. Wunderte mich auch nicht, da ich ja immer gerne die aktuelle PHP Version einsetze, und das Zeug eben nicht so schnell getestet werden kann. (Seit gestern habe ich auch v4.4.1 drauf, z.B.)
Ich versuche es jetzt aber mal wieder mit eA. Scheint so weit auch hervorragend zu laufen! Mal sehen, wie das auf längere Zeit wird.


da mach ich es mir etwas einfacher mit dem debian sarge php 4.3.10 zu dem dann immer sicherheitsupdates kommen... das läuft sowohl mit dem letzten turck als auch dem aktuellen eac stabil.

abraten kann ich nur von phpaccelerator. hatte schon unter woody probleme damit wenn viel last auf den server kam. unter sarge hab ich den garnicht mehr probiert.

[Odysseus]

Hm. PHPA hatte ich auf meinem vorherigen Server recht lange und stabil im Einsatz.
Das gibt es aber afair nur als Binary in der 32 Bit Version, und die lief nicht auf meinem Athlon 64 Server mit 64 Bit Linux.

Egal ... momentan scheint der eA ziemlich gut zu funktionieren! Die Load ist ziemlich drastisch gesunken, was zu erwarten war.

[waldbauer.com]

Hallo Leute !

Der Thread ist zwar schon recht alt, aber es gibt vom EAC einen aktuellen SVN266 , hat jemand zufällig diesen installiert und Erfahrungen damit ob und warum vbulletin nicht 100% damit läuft ?

Ich habe festgestellt, dass speziell editpost.php und newthread.php Probleme machen und musste daher den Cache abschalten.

Vielen Dank

[ugr|dual]

benutze noch den eac von 11/2005 und habe damit eigentlich keine probleme.

bist du sicher das du nicht nur mal den cache leeren musst?

[waldbauer.com]

Ich habe mal alternativ gerade den APC installiert und festgestellt, dass auch der in unserer Konfiguaration mit dem vbulletin nicht geht. Teilweise weisse Seiten, usw.

Wir haben PHP 5.1.6 als ISAPI auf W32.

[ugr|dual]

php 4 auf debian 3.1 - nicht wirklich vergleichbar. ^^

weisse seiten bei php... da war doch was mit dem IIS und nicht korrektem php handling? hatte das problem auch mal auf einem intranet server.

[BlueEyesOnly]

Zum Thema "suexec" hat noch keiner etwas gesagt.

Das würde ich auf jedenfall drin behalten, weil das seinem Apache erlaubt, alle Prozesse als ein normaler Benutzer (ohne Rechte) auf dem System laufen zu lassen. Bei SuSE ist das www-data, ein User, der normalerweise als shell /bin/false hat.
Wenn Apache als Root läuft und jemand eine Lücke für nen inject oder sowas findet, hat er die volle Kontrolle über dein System.

[Tomek]

suexec ist nur sinnvoll, wenn mehrere verschiedene VHosts getrennt voneinander laufen sollen. Ansonsten kostet es nur Systemleistung. Der Apache-Server wird standardmässig bereits mit einem unprivilegiertem Benutzer ausgeführt. Ob ein Exploit dann mit dem Apache-User oder einem anderen ausgeführt wird, ist unerheblich.

[BlueEyesOnly]

Achso, wusste ich nicht ;)

[Silmarillion]

darauf verzichtet. Bringt das einen niedrigen RAM Verbrauch ein?


ICh habe jetzt mal diesen eAccelerator installiert.

Ich versuche es jetzt aber mal wieder mit eA. Scheint so weit auch hervorragend zu laufen! Mal sehen, wie das auf längere Zeit wird.


Wie fällt denn Dein Fazit diesbezüglich aus, Odysseus?

mfg

[ugr|dual]

ich kann euch aktuell nur raten den APC als cache zu benutzen.

sowohl unter debian 3.1 (mysql 4.0/4.1 und php 4.4) sowie debian 4.0 (mysql 5, php5) sehr performant und stabil. der eac hat es nicht besser hinbekommen. APC wird jedoch stetig weiterentwickelt.

das einzige was APC nicht kann ist die scripts im cache komprimieren. man muss also etwas mehr speicher reservieren. eac habe ich mit 32 mb benutzt, für APC brauche ich aktuell 48 mb.

APC bringt auch eine brauchbare verwaltung via webserver mit.

selber kompilieren ist angesagt, ist aber kein ding..

http://pecl.php.net/package/apc

[Silmarillion]

Funktioniert APC denn auch mit der neuesten Zend Optimizer Version?

mfg

[ugr|dual]

kann ich nichts zu sagen, benutze ich nicht.