Apache 2 (MPM worker) + PHP5

[navti]

Hallo,

ich versuche schon seit 2 Tagen Apache 2.0.52 mit dem Worker-Modul und PHP 5.0.1 zum laufen zu bringen aber leider komme ich nicht weiter. OS ist übrigens Suse 8.

Ich habe Apache kompiliert mit

Code: Select all

./configure --prefix=/usr/local/apache2/2.0.52/ --enable-deflate --enable-rewrite --enable-so --with-mpm=worker 

Wenn ich den Apache danach starte, dann klappt alles besten. Es kommt die Apache Testseite auf der steht, dass der Apache richtig installiert worden ist.

Gut, dann kam PHP

Code: Select all

./configure --prefix=/usr/local/php/5.0.2/ --with-mysql=/usr/local/mysql/4.0.21/ --with-apxs2=/usr/local/apache2/2.0.52/bin/apxs 

Soweit so gut. Die Einbindung in die httpd.con funktioniert und auch das PHP Modul wird unter modules plaziert. Wenn ich aber nun den Server starten will, erhalte ich folgenden Fehler:
Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP.

Hat vielleicht noch jemand eine Idee was ich falsch mache bzw wie bin ich die Thread-Safety ein?

[oxygen]

Du musst PHP ohne Libarys kompilieren die nicht Threadsafe sind. Am besten schaust du mal bei ./configure welche Extensions Standardmäßig mit gebaut werden und schaltest erstmal alle aus. Danach dann in kleineren Schritten, die du brauchst an. Ich vermute aber gd wird das Problem sein.

[Joe User]

Die mm und readline Extensions sind definitiv nicht threadsafe, können also nur mit dem prefork MPM genutzt werden.
Anbei eines meiner Testscripts (Bitte selbst anpassen und nicht produktiv nutzen!):

Code: Select all

#!/bin/bash

cd /usr/src

wget http://www.apache.de/dist/httpd/httpd-2.0.52.tar.gz
wget http://de3.php.net/distributions/php-5.0.2.tar.bz2
wget http://tidy.sourceforge.net/src/tidy_src.tgz

tar xzf httpd-2.0.52.tar.gz
tar xjf php-5.0.2.tar.bz2
tar xzf tidy_src.tgz

cd /usr/src/tidy
/bin/sh build/gnuauto/setup.sh
CFLAGS="-O2 -pipe -march=pentium3 -mmmx -msse -mfpmath=sse -fno-strict-aliasing" CXXFLAGS="-O2 -pipe -march=pentium3 -mmmx -msse -mfpmath=sse -fno-strict-aliasing" ./configure --prefix=/usr && make && make install

cd /usr/src/httpd-2.0.52
ln -sf /etc/apache2 /etc/apache2/conf
patch -lNp1 < /usr/src/httpd.diff
./buildconf
CFLAGS="-O2 -pipe -march=pentium3 -mmmx -msse -mfpmath=sse -fno-strict-aliasing -fPIC -Wall" CXXFLAGS="-O2 -pipe -march=pentium3 -mmmx -msse -mfpmath=sse -fno-strict-aliasing -fPIC -Wall" ./configure --enable-layout=SuSE91 --with-mpm=worker --enable-nonportable-atomics=yes --with-perl=`which perl` --enable-so --enable-modules="access actions alias asis auth autoindex cern_meta cgid deflate dir env expires headers imap include info log_config mime mime_magic negotiation rewrite setenvif status userdir" --enable-mods-shared="ssl" && make && make install

cd /usr/src/php-5.0.2
CFLAGS="-O2 -pipe -march=pentium3 -mmmx -msse -mfpmath=sse -fno-strict-aliasing" CXXFLAGS="-O2 -pipe -march=pentium3 -mmmx -msse -mfpmath=sse -fno-strict-aliasing" ./configure --prefix=/usr --datadir=/usr/share/php --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-_lib=lib --with-config-file-path=/etc --with-exec-dir=/usr/lib/php/bin --with-apxs2=/usr/sbin/apxs --disable-all --disable-ipv6 --disable-cgi --enable-cli --enable-sigchild --enable-short-tags --enable-libxml --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --enable-ctype --with-curl --with-curlwrappers --enable-dio --enable-dom --enable-ftp --with-gd --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-gmp --with-imap --with-imap-ssl --with-mcrypt --with-mhash --with-mysql=/usr --with-mysql-sock=/var/lib/mysql/mysql.sock --enable-pcntl --with-pcre-regex --enable-posix --enable-session --enable-shmop --enable-simplexml --enable-sockets --enable-spl --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-tidy --enable-tokenizer --enable-wddx --enable-xml --with-xmlrpc --with-xsl --with-pear --enable-maintainer-zts --enable-inline-optimization --enable-memory-limit && make && make install

strip -s -p /usr/bin/{tidy,tab2space,php} /usr/sbin/{ab,checkgid,htdbm,htdigest,htpasswd,httpd,logresolve,rotatelogs} /usr/lib/{libapr,libtidy}*.{a,so}* /usr/lib/apache2/*.so

[navti]

Also ich habe jetzt mal die Skript-Konfiguration von Joe User als Hilfestellung benutzt und folgendes daraus gemacht:

Code: Select all

./configure --prefix=/usr/local/php/5.0.2 --with-apxs2=/usr/local/apache2/2.0.52/bin/apxs --disable-all --disable-ipv6 --disable-cgi --enable-cli --enable-sigchild --enable-short-tags --enable-libxml --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --enable-ctype --with-curl --with-curlwrappers --enable-dio --enable-dom --enable-ftp --with-gd --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-gmp --with-mysql=/usr/local/mysql/4.0.21/ --enable-pcntl --with-pcre-regex --enable-posix --enable-session --enable-shmop --enable-simplexml --enable-sockets --enable-spl --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-tokenizer --enable-wddx --enable-xml --with-xmlrpc --with-xsl --with-pear --enable-maintainer-zts --enable-inline-optimization --enable-memory-limit

Leider bekomme ich immer noch die gleiche Fehlermeldung. Kann es evtl sein, dass beim Apache was schief gelaufen ist?

[andreask2]

ich versuche schon seit 2 Tagen Apache 2.0.52 mit dem Worker-Modul und PHP 5.0.1 zum laufen zu bringen

Das sollte man IMHO nicht machen, lies mal:
http://de3.php.net/manual/en/faq.instal ... on.apache2

Hat vielleicht noch jemand eine Idee was ich falsch mache bzw wie bin ich die Thread-Safety ein?

Das steht im Manual: http://de3.php.net/manual/en/install.unix.apache2.php
Da steht z.B.:

Code: Select all

Note:  To build a multithreaded version of Apache your system must support threads. This also implies to build PHP with experimental Zend Thread Safety (ZTS). Therefore not all extensions might be available. The recommended setup is to build Apache with the standard prefork MPM-Module.

In PHP4 gab es noch

Code: Select all

 --enable-experimental-zts   This will most likely break your build

In PHP5 finde ich das nicht mehr. Dafür steht in der TODO-Liste von PHP 5.0.2:

Code: Select all

Component:      Thread Safety
                Identify the extensions that are not thread safe by design
                or due to dependant libraries and identify them as such.
                If possible try to resolve thread safety issue via code
                improvements (if php code or patches will be accepted by
                library maintainers).   For situations where thread safety
                cannot easily be acheived a flag in the extension API is
                set so PHP can identify non-thread safe extensions.  These
                extensions will not be loaded in a ZTS compiled binary
                (unless it is cli/cgi).

Responsibility: ?
Time frame:     ?

Also, das ganze gilt immer noch als höchst experimentell, viele Extensions können nicht verwendet werden, bei vielen Extensions ist man sich nicht wirklich sicher ob es 100% funktioniert, es gibt eigentlich keine großartigen Vorteile wenn man einen Multithreaded Webserver mit PHP einsetzt (dafür aber eine Menge Nachteile), so ziemlich alle PHP-Entwickler halten dies für sinnlos, also wieso sollte man das wollen? Und selbst für statische Inhalte gibt es IMHO bessere(schnellere, "sparsamere") Konzepte, wie es z.B. lighttpd vorführt.


Grüße
Andreas

[kase]

Es gibt eine configure-Option, die du bei php5 aktivieren musst, damit es Thread-Safe ist, allerdings gibt es mom viel zu viele Extensions, die nicht Thread-Safe sind, weswegen ich diese Option hier auch nicht verrate.

IMHO ist es nur eine gute Idee, das ganze so zu benutzen, wenn du php mit --disable-all compilierst, und du das "reine" php hast, und selbst dann kann es zu Problemen kommen.

=> mod_php nur mit mpm-prefork

Willst du suphp oder fastcgi benutzen, kannst du das worker mpm benutzen, allerdings muss dann php als cgi kompiliert werden.

[Joe User]

http://de3.php.net/manual/en/faq.instal ... on.apache2

Diese Empfehlung ist seit dem Release von PHP 5.0.0 veraltet.

Code: Select all

 --enable-experimental-zts   This will most likely break your build

In PHP5 finde ich das nicht mehr.

--enable-maintainer-zts ;)

Also, das ganze gilt immer noch als höchst experimentell,

Wie bereits geschrieben, ist die Dokumentation diesbezüglich leider nicht up-to-date und somit unbrauchbar.

viele Extensions können nicht verwendet werden,

Generell nicht verwendbar ist derzeit (PHP <= 5.0.2) nur die MySQLi-Extension, wobei lediglich die mm und readline Extensions nicht threadsafe sind.

es gibt eigentlich keine großartigen Vorteile wenn man einen Multithreaded Webserver mit PHP einsetzt

Naja, die höhere Performance ist durchaus zu bemerken ;)

(dafür aber eine Menge Nachteile),

Welche?

so ziemlich alle PHP-Entwickler halten dies für sinnlos,

Quelle(n)?

BTW: Ich setze worker/mod_php4 seit PHP 4.3.2 und worker/mod_php5 seit PHP 5.0.1 (5.0.0 enthielt noch den (fast) vollständigen Debugcode) produktiv ein...

[kase]

Wieso ist die mysqli extension in php 5.0.2 nicht verwendbar?

[Joe User]

Wieso ist die mysqli extension in php 5.0.2 nicht verwendbar?

Zuviele Bugs, siehe Changelog ;)

[andreask2]

Hallo Joe!

http://de3.php.net/manual/en/faq.instal ... on.apache2

Diese Empfehlung ist seit dem Release von PHP 5.0.0 veraltet.

Wer sagt das? Rasmus Lerdorf hält sogar den Einsatz von Apache 2 prinzipiell - zumindest unter "PHP-Gesichtspunkten" für die schlechtere Alternative gegenüber 1.3. Das sehe ich zwar nicht unbedingt so - zumal es ihm wohl auch darum geht, dass viele (unter anderem auch eigene) Apache-Module nicht für 2.0 verfügbar sind. Aber das lässt sich ja nicht unbedingt verallgemeinern. Bzgl. multithreading sieht er es aber ganz klar so - dass sich sowas für Script-Sprachen wie PHP einfach nicht eignet - eben wegen der vielen externen Bibliotheken, wo man sich oft nicht wirklich sicher sein kann, dass es hier keine Probleme geben wird. Es gibt zu viele Einflussfaktoren um sich hier wirklich sicher zu sein (siehe Zitate unten).

--enable-maintainer-zts ;)

ja, aber man beachte den Kommentar:

Code: Select all

--enable-maintainer-zts Enable thread safety - for code maintainers only

Bist Du das? ;-)

Also, das ganze gilt immer noch als höchst experimentell,

Wie bereits geschrieben, ist die Dokumentation diesbezüglich leider nicht up-to-date und somit unbrauchbar.

Diese Frage wurde in die FAQ aufgenommen, nachdem das dort zum 1000sten mal auf php.internals/php.general diskutiert wurde, Anlass und Vorlage hierfür war das Posting von Rasmus vom Juni diesen Jahres: http://marc.theaimsgroup.com/?l=php-dev ... 021355&w=2
Meines Wissens wurde dieser Punkt den FAQ erst nach dem offiziellen Release von PHP5 hinzugefügt, und eben auch erst danach aus der frisch überarbeiteten Installations-Anleitung (jetzt übrigens auch mit dedizierten Gentoo-Hinweisen ;-)) verlinkt. Das was ich bzgl. TODO und Thread-Safety zitiert habe, stammte aus dem PHP 5.0.2 Source! Und es sei ebenfalls angemerkt, dass für diese Aufgabe - im Gegesatz zu den meisten anderen - weder ein Entwicker zugewiesen war, noch ein zeitlicher Rahmen gesteckt war.

Generell nicht verwendbar ist derzeit (PHP <= 5.0.2) nur die MySQLi-Extension, wobei lediglich die mm und readline Extensions nicht threadsafe sind.

Wie kannst Du da so sicher sein? http://httpd.apache.org/docs-2.1/develo ... ml#liblist ist zwar nicht auf dem allerneusten Stand, aber dass inzwischen alle Probleme dort behoben sind wage ich zu bezweifeln.

Und ich zitiere nochmal von php.internals:

Code: Select all

Note also that most developers who tell you their code is threadsafe don't 
really know if that is true.  All code relies on external things that may 
or may not be threadsafe and we don't have any tools to verify claims of 
thread safety.

http://marc.theaimsgroup.com/?l=php-dev ... 626764&w=2

Naja, die höhere Performance ist durchaus zu bemerken ;)

Gemessen? Ja, bei statischen Requests natürlich, aber auch bei PHP? Vor allem unter Last bei komplexeren Scripten? Das sehen nicht alle so (siehe Zend Whitepaper unten).

(dafür aber eine Menge Nachteile),

Welche?

- nicht reproduzierbare Abstürze unter hoher Last
- langsamer unter Last (bezogen auf PHP)
- neuere erheblich weniger getestete Software nötig

aus dem php.internals Posting von oben:

Code: Select all

Someone was using an
early version of Apache2 with the PostgreSQL libpq client library.  The
PostgreSQL developers swore up and down that their library was threadsafe
and I spent a whole day eliminating libraries one by one.  Luckily this
particular problem was somewhat reproducable.  If I banged hard enough at
one section which created new accounts every now and then an account would
end up with a bogus password entry and the user wouldn't be able to log
in.  It turned out that libpq was using the system's crypt() function
which was not threadsafe.  So the account creation which used something
line INSERT INTO users ... CRYPT($password)... would mess up when 2 or
more threads were trying to do this at the same time.  This wasn't PHP's
fault in any way, it wasn't really PostgreSQL's fault either, but it was
still broken.

so ziemlich alle PHP-Entwickler halten dies für sinnlos,

Quelle(n)?

Es ist inzwischen einfach Konsens. Nochmal aus obigem Thread:

Code: Select all

A threaded web server behind a general-purpose scripting language like 
Perl or PHP simply makes no sense to me.  You want a robust and simple 
base platform to layer your application on top of.

Man findet in den verlinkten Threads Aussagen mehrerer Entwickler, aber wie gesagt, es befinden sich wirklich viele Diskussionen in den Archiven. Mit PHP5 änder sich auch daran nichts, denn schon PHP4 selber war schon sehr lange Threadsafe. Es gibt sicher mhr und mehr Bibliotheken die von sich behaupten Thredsafe zu sein, was aber nicht immer stimmt (siehe Beispiel pgsql im Thread), einige werden es womöglich nie werden. Es bringt (zumindestens nach Aussagen von Zend) keine Performance-Verteile (auf Seiten von PHP) - im Gegenteil (Siehe Whitepaper unten).

z.B. verwendet auch Ilia entsprechendes in der Präsentation "Accelerating PHP Applications" von vor wenigen Wochen http://talks.php.net/show/acc_php/7 .

George Schlossnagle beschreibt das z.B. in seinem Buch "Advanced PHP Programming" (Das beste PHP-Buch das ich kenne, gibt inzwischen auch übersetzt)
http://www.amazon.de/exec/obidos/tg/det ... schloss-20

http://simon.incutio.com/archive/2004/0 ... AndApache2

und auch das Zend-Whitepaper unten geht darauf ein.

BTW: Ich setze worker/mod_php4 seit PHP 4.3.2 und worker/mod_php5 seit PHP 5.0.1 (5.0.0 enthielt noch den (fast) vollständigen Debugcode) produktiv ein...

Und warum? Brauchtest Du diese kleine bisschen Extra-Performance?

Zu diesem Thema mal aus einem Whitepaper von Zend:

Code: Select all

 If you plan on using your server primarily for serving PHP content, then running your server in multithreaded mode may actually slow you down by as much as 15%! This overhead originates in the extra work that PHP has to do in order to be thread-safe, including locking and passing around per-thread contexts to all functions

Quelle: http://www.zend.com/whitepapers/PHPandA ... epaper.pdf

Wenn Du keine besonders hohe Last hast, dann mal folgendes Zitat von Rasmus Posting aus php.internals (s.o.):

Code: Select all

 Hundreds of people may well post to this list that
Apache+PHP+ext/foo works perfectly for them, but maybe they are only
getting about a million hits a day.  Then another user comes along who
gets 100 million hits a day and uses a fast dual-cpu machine and
everything blows up because now suddenly the window for some tiny race
condition has been made much larger due to the faster cpu speeds, the
second cpu and the higher frequency of requests.  And the bug report we
get from this user will be something along the lines of:

  It don't work sometimes.  Most of the times it works fine, but then
  every now and then it just don't.  The error is different each time
  and I have no idea how to reproduce it, but fix it right away!!!

Linux - Apache - mod_php ist eine sehr, sehr robuste Architektur. Es skaliert durch sein einfaches "fire & forget" erheblich besser als so manche gehypte AppServer Architektur. Das alles gefährdet man durch den Einsatz von multithreaded Webservern. Sicher ist das Prinzip des Worker-MPMs dem Prefork-MPM vorzuziehen wenn es um statische Inhalte geht, dann sollte man aber getrennte Server verwenden.

http://www.schlossnagle.org/~george/blo ... ndard.html

Und wie gesagt, für statische Inhalte IMHO noch besser ist der Ansatz von nonblocking bzw. asynchronous I/O wie z.B. lighttpd.

http://incremental.de/talks/phpconf-200 ... ge.23.html
http://jan.kneschke.de/projects/lighttpd/benchmark/


Viele Grüße
Andreas

[Joe User]

Moin Andreas,

http://de3.php.net/manual/en/faq.instal ... on.apache2

Diese Empfehlung ist seit dem Release von PHP 5.0.0 veraltet.

Wer sagt das? Rasmus Lerdorf hält sogar den Einsatz von Apache 2 prinzipiell - zumindest unter "PHP-Gesichtspunkten" für die schlechtere Alternative gegenüber 1.3.

Apache2.0-prefork und Apache1.3 verhalten sich aus "PHP-Gesichtspunkten" gleich (vgl. Apache2-Manual) und auf dieser Basis baut auch die Aussage von R.L. auf. Die oben genannte FAQ wurde zu einem Zeitpunkt verfasst, als PHP5 noch in einem frühen Alpha-Stadium war und wurde inhaltlich nie überarbeitet. Zu dem Zeitpunkt war übrigens auch Apache2 noch im Beta-Stadium, klingelt's? ;)

Bzgl. multithreading sieht er es aber ganz klar so - dass sich sowas für Script-Sprachen wie PHP einfach nicht eignet - eben wegen der vielen externen Bibliotheken, wo man sich oft nicht wirklich sicher sein kann, dass es hier keine Probleme geben wird. Es gibt zu viele Einflussfaktoren um sich hier wirklich sicher zu sein (siehe Zitate unten).

Man merkt den Unterschied bereits bei kleineren Projekten in der Grössenordnung des RootForum. Zudem kompiliert man zum produktiven Einsatz grundsätzlich nur die benötigten Extensions ein und nicht einfach Alle, frei nach dem Motto: "Könnte man ja irgendwann mal nutzen..."

--enable-maintainer-zts ;)

ja, aber man beachte den Kommentar:

Code: Select all

--enable-maintainer-zts Enable thread safety - for code maintainers only

Bist Du das? ;-)

Ja, auf jedem meiner Server ;)

Meines Wissens wurde dieser Punkt den FAQ erst nach dem offiziellen Release von PHP5 hinzugefügt,

Nö, es steht seit einer der ersten öffentlichen Alpha-Versionen in der Doku.

Generell nicht verwendbar ist derzeit (PHP <= 5.0.2) nur die MySQLi-Extension, wobei lediglich die mm und readline Extensions nicht threadsafe sind.

Wie kannst Du da so sicher sein? http://httpd.apache.org/docs-2.1/develo ... ml#liblist ist zwar nicht auf dem allerneusten Stand, aber dass inzwischen alle Probleme dort behoben sind wage ich zu bezweifeln.

Abgesehen davon, dass ich mich auf die PHP-Extensions bezog: Welche der aufgeführten als nicht-threadsafe gekennzeichneten Libs benötigt der HTTPd auf einem durchschnittlichen "RootServer"?

Und ich zitiere nochmal von php.internals:

Code: Select all

Note also that most developers who tell you their code is threadsafe don't 
really know if that is true.  All code relies on external things that may 
or may not be threadsafe and we don't have any tools to verify claims of 
thread safety.

http://marc.theaimsgroup.com/?l=php-dev ... 626764&w=2

Wenn die PHP-Devs keine derartigen Tools beziehungsweise Testumgebungen nutzen, können sie auch nicht verifizieren, ob eine Lib threadsafe ist. Dies ist allerdings nicht den Maintainern der Libs, sondern höchstens den PHP-Devs vorzuwerfen, schliesslich haben dann die PHP-Devs blindlings ungeprüften Code (vgl. Dein Zitat zur PostgreSQL libpq) implementiert. Allein aus sicherheitstechnischen Gesichtspunkten heraus ist soetwas indiskutable Frickelei. (Es wird OffTopic...)

Naja, die höhere Performance ist durchaus zu bemerken ;)

Gemessen?

Ja.

Ja, bei statischen Requests natürlich, aber auch bei PHP? Vor allem unter Last bei komplexeren Scripten?

Leider existiert meine damalige Testumgebung nicht mehr, sonst hätte ich ein paar Zahlen nennen können (Benchmarks führe ich in produktiven Umgebungen grundsätzlich nicht durch).

Es gibt sicher mhr und mehr Bibliotheken die von sich behaupten Thredsafe zu sein, was aber nicht immer stimmt (siehe Beispiel pgsql im Thread), einige werden es womöglich nie werden.

ACK.

Es bringt (zumindestens nach Aussagen von Zend) keine Performance-Verteile (auf Seiten von PHP) - im Gegenteil (Siehe Whitepaper unten).

Zend muss seine Produkte verkaufen...

BTW: Ich setze worker/mod_php4 seit PHP 4.3.2 und worker/mod_php5 seit PHP 5.0.1 (5.0.0 enthielt noch den (fast) vollständigen Debugcode) produktiv ein...

Und warum? Brauchtest Du diese kleine bisschen Extra-Performance?

Ja.

Zu diesem Thema mal aus einem Whitepaper von Zend:

Code: Select all

 If you plan on using your server primarily for serving PHP content, then running your server in multithreaded mode may actually slow you down by as much as 15%! This overhead originates in the extra work that PHP has to do in order to be thread-safe, including locking and passing around per-thread contexts to all functions

NPTL.

Wenn Du keine besonders hohe Last hast, dann mal folgendes Zitat von Rasmus Posting aus php.internals (s.o.):

http://www.gaiaonline.com/forum/ wird derzeit von ~50 Servern serviert, nicht von einem. Eventuell sollte R.L. sich mal wieder in die Realität begeben? Ansonsten ein recht nettes Zitat, danke.

Linux - Apache - mod_php ist eine sehr, sehr robuste Architektur. Es skaliert durch sein einfaches "fire & forget" erheblich besser als so manche gehypte AppServer Architektur.

ACK.

Das alles gefährdet man durch den Einsatz von multithreaded Webservern.

Nein, die Gefahr geht nicht von multithreaded Webservern, sondern von unerfahrenen Administratoren, sowie leichtsinnigen (siehe oben) beziehungsweise unfähigen Programmierern aus.

Gruss,
Joe User

PS: Nochmal Danke für die drei mir bis dato unbekannten Links ;)

[kase]

Zuviele Bugs, siehe Changelog ;)

Hmm, also ich setze schon seit PHP 5.0.0 nur noch mySQLi ein, und habe eigentlich keine Probleme.

Und auch in der Changelog von 5.0.0 bis 5.0.2 gibt es gerade mal 2 Bugs in der Client-Libary, die aber von Georg behoben wurden.

Aber vielleicht hast du ja noch ein paar andere "Quellen" für mich? ;)

edit: open bugs for mysqli: http://bugs.php.net/search.php?search_f ... Li+related

[Joe User]

Aber vielleicht hast du ja noch ein paar andere "Quellen" für mich? ;)

Aus dem CVS-Changelog (Stand 11.12.2004) (gekürzt):

Code: Select all

2004-12-09  Antony Dovgal
      fix buffer overrun and remove debug printf() call

2004-12-04  Georg Richter
      fix for bug #28817 (properties don't work in extended class)

2004-12-03  Georg Richter
      Fixed bug #30967 (properties in extended mysqli classes don't work)

2004-11-01  Georg Richter
      Added default multi resultset support for mysqli_connect (#30645)
      Fixed tests for empty dates (see http://bugs.mysql.com/?id=6058)
      Fixed memleak in mysqli_stmt_bind_result
      Fixed error handling for mysqli_multi_query

2004-10-19  Georg Richter
      Minor fix for mysqli_connect: checking socket_len for NULL Values
...

;)

EDIT:
Aus der INSTALL (Stand 05.12.2004):

Code: Select all

Apache 2.0 on Unix systems

   This section contains notes and hints specific to Apache 2.0 installs
   of PHP on Unix systems.

   Warning

   Do not use Apache 2.0.x and PHP in a production environment neither on
   Unix nor on Windows. For information on why, read the following FAQ
   entry

   You are highly encouraged to take a look at the Apache Documentation
   to get a basic understanding of the Apache 2.0 Server.

     PHP and Apache 2.0.x compatibility notes: The following versions of
     PHP are known to work with the most recent version of Apache 2.0.x:

     * PHP 4.3.0 or later available at http://www.php.net/downloads.php.
     * the latest stable development version. Get the source code
       http://snaps.php.net/php4-latest.tar.gz or download binaries for
       Windows http://snaps.php.net/win32/php4-win32-latest.zip.
     * a prerelease version downloadable from http://qa.php.net/.
     * you have always the option to obtain PHP through anonymous CVS.

     These versions of PHP are compatible to Apache 2.0.40 and later.

     Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 works
     with Apache 2.0.39, don't use any other version of Apache with PHP
     4.2.3. However, the recommended setup is to use PHP 4.3.0 or later
     with the most recent version of Apache2.

     All mentioned versions of PHP will work still with Apache 1.3.x.

   Download the most recent version of Apache 2.0 and a fitting PHP
   version from the above mentioned places. This quick guide covers only
   the basics to get started with Apache 2.0 and PHP. For more
   information read the Apache Documentation. The version numbers have
   been omitted here, to ensure the instructions are not incorrect. You
   will need to replace the 'NN' here with the correct values from your
   files.

[kase]

Code: Select all

2004-10-19  Georg Richter
      Minor fix for mysqli_connect: checking socket_len for NULL Values

Wenn man die Funktion _richtig_ benutzt, sollte das kein Problem sein.

Code: Select all

2004-11-01  Georg Richter
      Added default multi resultset support for mysqli_connect (#30645)
      Fixed tests for empty dates (see http://bugs.mysql.com/?id=6058)
      Fixed memleak in mysqli_stmt_bind_result
      Fixed error handling for mysqli_multi_query

Ok, hier sind wirklich ein paar schlimmere Bugs dabei, allerdings sollten die ja alle in php 5.0.2 oder sogar schon in php 5.0.1 behoben sein.

Code: Select all

2004-12-04  Georg Richter
      fix for bug #28817 (properties don't work in extended class)

2004-12-03  Georg Richter
      Fixed bug #30967 (properties in extended mysqli classes don't work)

Schon seit den RCs (Beta) bekanntes Problem, dass sich die mysqli Klasse nicht extenden lässt, stand IMHO sogar direkt in der Docu drin, schön, dass das jetzt behoben ist... ;)

...


Wie gesagt, ich selbst benutze die mysqli Klasse schon recht ausgiebig, und auch in größeren Projekten, die stark Datenbank basierend sind, und habe keinerlei Probleme, kann nur empfehlen, von mysql auf mysqli umzusteigen.

[Joe User]

Code: Select all

2004-11-01  Georg Richter
      Added default multi resultset support for mysqli_connect (#30645)
      Fixed tests for empty dates (see http://bugs.mysql.com/?id=6058)
      Fixed memleak in mysqli_stmt_bind_result
      Fixed error handling for mysqli_multi_query

Ok, hier sind wirklich ein paar schlimmere Bugs dabei, allerdings sollten die ja alle in php 5.0.2 oder sogar schon in php 5.0.1 behoben sein.

Aus dem Changelog:

Code: Select all

2004-09-23  Andi Gutmans
    * (PHP_5_0)
      NEWS
      configure.in
      ZendEngine2/zend.h
      main/php_version.h:
      - Roll 5.0.2

Schon seit den RCs (Beta) bekanntes Problem, dass sich die mysqli Klasse nicht extenden lässt, stand IMHO sogar direkt in der Docu drin, schön, dass das jetzt behoben ist... ;)

;)

Wie gesagt, ich selbst benutze die mysqli Klasse schon recht ausgiebig, und auch in größeren Projekten, die stark Datenbank basierend sind, und habe keinerlei Probleme, kann nur empfehlen, von mysql auf mysqli umzusteigen.

Du schreibst die Projekte selbst und kannst bei Bedarf auch selbst entsprechende Workarounds basteln, "Ich habe ein Script im Internet gefunden"-User (die Mehrzahl unserer User) können dies (im Regelfall) nicht und fallen dann voll auf die Schnauze...

[andreask2]

Apache2.0-prefork und Apache1.3 verhalten sich aus "PHP-Gesichtspunkten" gleich (vgl. Apache2-Manual) und auf dieser Basis baut auch die Aussage von R.L. auf. Die oben genannte FAQ wurde zu einem Zeitpunkt verfasst, als PHP5 noch in einem frühen Alpha-Stadium war und wurde inhaltlich nie überarbeitet. Zu dem Zeitpunkt war übrigens auch Apache2 noch im Beta-Stadium, klingelt's? ;)

Nein ;-)
Das war damals eine Diskussion, die mich sehr interessiert hat. Du meinst vermutlich die Anmerkung in der Installations-Anleitung. Das ist schon lange da, ja. Aber es wurde ganz bewußt nicht geändert! Es wurde nur der Link zu den FAQ hinzugefügt, der Punkt der FAQ war vor 6 Monaten noch nichtmal im CVS: http://cvs.php.net/co.php/phpdoc/en/faq ... xml?r=1.28 (gegenüber http://cvs.php.net/co.php/phpdoc/en/faq ... xml?r=1.29).

Es ging darum, dass der Apache 2 so gut wie komplett neu geschrieben wurde, das Problem der 3rd Party Extensions mit der thread-safety, und dass so prefork das einzig zuverlässige MPM war, welches allerdings keinen Vorteil bot gegenüber Apache 1.3, im Gegenteil wurde und wird Apache 1.3 millionenfach auch in sehr großen Umgebungen erfolgreich eingesetzt, dieses Vertrauen in die Zuverlässigkeit muss sich Apache 2 erst noch erarbeiten. Inzwischen sehe ich es aber so, dass Apache 2 Prefork wirklich stabil genug arbeitet, ich meine, die erste Beta ist schon einige Jahre her, und auch das stabile Release. Aber wie gesagt - die Mehrheit der PHP-Devs sieht selbst das noch anders! Auch heute noch. Zu dem Thema nochmal ein Posting: http://marc.theaimsgroup.com/?l=php-dev ... 231093&w=2

Bei Apache mit Worker MPM sieht es aber so aus - dass dies vermutlich nie von den PHP-Entwicklern empfohlen wird, eben weil die Risiken gegenüber dem Nutzen viel zu groß sind, und vermeidbar sind.

Bzgl. multithreading sieht er es aber ganz klar so - dass sich sowas für Script-Sprachen wie PHP einfach nicht eignet - eben wegen der vielen externen Bibliotheken, wo man sich oft nicht wirklich sicher sein kann, dass es hier keine Probleme geben wird. Es gibt zu viele Einflussfaktoren um sich hier wirklich sicher zu sein (siehe Zitate unten).

Man merkt den Unterschied bereits bei kleineren Projekten in der Grössenordnung des RootForum. Zudem kompiliert man zum produktiven Einsatz grundsätzlich nur die benötigten Extensions ein und nicht einfach Alle, frei nach dem Motto: "Könnte man ja irgendwann mal nutzen..."

Aber wie beim pg-Beispiel - das Problem bestand dort in einer genutzten Systembibliothek - wer soll das denn alles beachten können? Die Frage ist auch - welche Optimierungs-Potentiale bereits ausgeschöpft wurden, siehe Link zur Präsentation von Ilia.

Meines Wissens wurde dieser Punkt den FAQ erst nach dem offiziellen Release von PHP5 hinzugefügt,

Nö, es steht seit einer der ersten öffentlichen Alpha-Versionen in der Doku.

Ich meine nicht den Vermerk in der Installations-Doku, sondern den Punkt in den FAQ, sie CVS-Link oben.

http://httpd.apache.org/docs-2.1/develo ... ml#liblist

Abgesehen davon, dass ich mich auf die PHP-Extensions bezog: Welche der aufgeführten als nicht-threadsafe gekennzeichneten Libs benötigt der HTTPd auf einem durchschnittlichen "RootServer"?

so ungewöhnlich sieht mir http://httpd.apache.org/docs-2.1/develo ... commonlibs z.B. nicht aus. Vor allem wenn Du bei Root-Server an Wohnzimmer-Provider denkst wird es besonders hart ;-)

Wenn die PHP-Devs keine derartigen Tools beziehungsweise Testumgebungen nutzen, können sie auch nicht verifizieren, ob eine Lib threadsafe ist.

Was gibt es denn da für Tools? Wie soll eine Testumgebung aussehen? Die Fehler treten ja nur unter ganz besonderen Bedingungen auf, die man unmöglich alle simulieren kann. Wie gesagt, PHP selber gilt schon länger (ich glaube sogar schon seit Anfgang von PHP4!) als Threadsafe.

Dies ist allerdings nicht den Maintainern der Libs, sondern höchstens den PHP-Devs vorzuwerfen, schliesslich haben dann die PHP-Devs blindlings ungeprüften Code (vgl. Dein Zitat zur PostgreSQL libpq) implementiert. Allein aus sicherheitstechnischen Gesichtspunkten heraus ist soetwas indiskutable Frickelei. (Es wird OffTopic...)

Deswegen steht in der Anleitung, in den FAQ, in den Kommentaren bei ./configure --help... dass man es doch bitte lassen soll, dass es experiemtnell ist und dass man mit Sicherheit Probleme bekommt. _Du_ bist derjenige dem das egal ist und sowas in produktiven Umgebungen einsetzt - dafür kannst Du doch nicht jemand anderen verantwortlich machen. Sowas wie mod_php von A-Z threadsafe zu bekommen ist keine triviale Aufgabe (wenn nicht unmöglich), PHP-Devs sind auch nur Menschen. Zumal es effizientere Ansätze gibt als einen multithreaded (bzw. hybriden, weil auch multi-prozess) Webserver zu verwenden. Einer wäre wie gesagt ein schlanker Webserver in einem Thread, der per fastcgi feste (loadbalanced) PHP-Prozesse verwendet (lighttpd), ein Opcode Cache, statisch kompilieren bzw. ohne PIC, HTTP-Caching, Trennung von statischem und dynamischem...

Es bringt (zumindestens nach Aussagen von Zend) keine Performance-Verteile (auf Seiten von PHP) - im Gegenteil (Siehe Whitepaper unten).

Zend muss seine Produkte verkaufen...

was hat das damit zu tun? Wüßte nicht dass Zend Webserver verkauft. Denen kann es doch prinzipiell egal sein auf welcher Plattform die mit der eigenen IDE entwickelten Scripte laufen, oder in welchem Webserver jetzt deren ZPS... verwendet wird. Kann Dein Argument nicht nachvollziehen.

Zu diesem Thema mal aus einem Whitepaper von Zend:

Code: Select all

 If you plan on using your server primarily for serving PHP content, then running your server in multithreaded mode may actually slow you down by as much as 15%! This overhead originates in the extra work that PHP has to do in order to be thread-safe, including locking and passing around per-thread contexts to all functions

NPTL.

Gut, das kann sein. Aber verwendest Du die schon? In einem 2.6er Kernel? Außerdem ist der Apache mit Worker MPM auch kein reiner Multithreaded Webserver.

Wenn Du keine besonders hohe Last hast, dann mal folgendes Zitat von Rasmus Posting aus php.internals (s.o.):

http://www.gaiaonline.com/forum/ wird derzeit von ~50 Servern serviert, nicht von einem. Eventuell sollte R.L. sich mal wieder in die Realität begeben? Ansonsten ein recht nettes Zitat, danke..

Wie meinst Du das? Rasmus arbeitet für Yahoo an der mit Abstand größten PHP-Installation der Welt: http://talks.php.net/show/lt2004-lamp/1 , und auch einige andere der Devs arbeiten an sehr großen Installationen, oder für große Provider.

Das alles gefährdet man durch den Einsatz von multithreaded Webservern.

Nein, die Gefahr geht nicht von multithreaded Webservern, sondern von unerfahrenen Administratoren,

Du meinst die die sich nicht drum kümmern wenn die Devs da hinschreiben "experimentell - DONT USE!!!!" ?

*SCNR*

sowie leichtsinnigen (siehe oben) beziehungsweise unfähigen Programmierern aus.

Wenn ich ein Programm vor langer Zeit geschrieben habe und einfach nicht für Threads vorgesehen habe - bin ich dann unfähig? Aus heutiger Sicht sagt sich sowas leicht.

PS: Nochmal Danke für die drei mir bis dato unbekannten Links ;)

kein Thema ;-)

[kase]

Hups, wusste nicht, dass es php 5.0.2 schon sooo lange gibt (wie schnell doch die Zeit vergeht^^), dann warte ich mal gespannt auf das bald kommende 5.0.3 ;)

Allerdings hat mir bisher noch kein einziger dieser Bugs ein Problem bereitet, obwohl ich wie gesagt intensiv mit mysqli arbeite...

[Joe User]

Moin,

Apache2.0-prefork und Apache1.3 verhalten sich aus "PHP-Gesichtspunkten" gleich (vgl. Apache2-Manual) und auf dieser Basis baut auch die Aussage von R.L. auf. Die oben genannte FAQ wurde zu einem Zeitpunkt verfasst, als PHP5 noch in einem frühen Alpha-Stadium war und wurde inhaltlich nie überarbeitet. Zu dem Zeitpunkt war übrigens auch Apache2 noch im Beta-Stadium, klingelt's? ;)

Nein ;-)
Das war damals eine Diskussion, die mich sehr interessiert hat. Du meinst vermutlich die Anmerkung in der Installations-Anleitung. Das ist schon lange da, ja.

Einigen wir uns auf Dokumentation? ;)

Es ging darum, dass der Apache 2 so gut wie komplett neu geschrieben wurde, das Problem der 3rd Party Extensions mit der thread-safety, und dass so prefork das einzig zuverlässige MPM war, welches allerdings keinen Vorteil bot gegenüber Apache 1.3, im Gegenteil wurde und wird Apache 1.3 millionenfach auch in sehr großen Umgebungen erfolgreich eingesetzt, dieses Vertrauen in die Zuverlässigkeit muss sich Apache 2 erst noch erarbeiten.

Nur weil viele Admins noch immer "Never change a runnung system." praktizieren, soll die Zuverlässigkeit von Apache2 noch öfter unter Beweis gestellt werden?

Inzwischen sehe ich es aber so, dass Apache 2 Prefork wirklich stabil genug arbeitet, ich meine, die erste Beta ist schon einige Jahre her, und auch das stabile Release. Aber wie gesagt - die Mehrheit der PHP-Devs sieht selbst das noch anders! Auch heute noch.

Nochmal aus der INSTALL (Stand 05.12.2004):

Code: Select all

     PHP and Apache 2.0.x compatibility notes: The following versions of
     PHP are known to work with the most recent version of Apache 2.0.x:

     * PHP 4.3.0 or later available at http://www.php.net/downloads.php.
     * the latest stable development version. Get the source code
       http://snaps.php.net/php4-latest.tar.gz or download binaries for
       Windows http://snaps.php.net/win32/php4-win32-latest.zip.
     * a prerelease version downloadable from http://qa.php.net/.
     * you have always the option to obtain PHP through anonymous CVS.

     These versions of PHP are compatible to Apache 2.0.40 and later.

     Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 works
     with Apache 2.0.39, don't use any other version of Apache with PHP
     4.2.3. However, the recommended setup is to use PHP 4.3.0 or later
     with the most recent version of Apache2.

Letzter Satz...

Dies ist allerdings nicht den Maintainern der Libs, sondern höchstens den PHP-Devs vorzuwerfen, schliesslich haben dann die PHP-Devs blindlings ungeprüften Code (vgl. Dein Zitat zur PostgreSQL libpq) implementiert. Allein aus sicherheitstechnischen Gesichtspunkten heraus ist soetwas indiskutable Frickelei. (Es wird OffTopic...)

Deswegen steht in der Anleitung, in den FAQ, in den Kommentaren bei ./configure --help... dass man es doch bitte lassen soll, dass es experiemtnell ist und dass man mit Sicherheit Probleme bekommt.

Wenn Du jede dieser "Warnungen" beachtest, bleibt Dir nichteinmal mehr 20% der Funktionalität von PHP erhalten.

_Du_ bist derjenige dem das egal ist und sowas in produktiven Umgebungen einsetzt - dafür kannst Du doch nicht jemand anderen verantwortlich machen.

man Produkthaftung

Sowas wie mod_php von A-Z threadsafe zu bekommen ist keine triviale Aufgabe (wenn nicht unmöglich), PHP-Devs sind auch nur Menschen.

PHP selbst ist threadsafe, nur ein paar (z.B. mm und readline) Extensions sind es nicht.

Zumal es effizientere Ansätze gibt als einen multithreaded (bzw. hybriden, weil auch multi-prozess) Webserver zu verwenden.

Wozu stellt man sich ein Multiprozessor/HT-System als Webserver ins Rack, wenn man dann eh nur einen Prozessor nutzen kann?

ohne PIC

Aus sicherheitstechnischen Aspekten nicht zu empfehlen.

Es bringt (zumindestens nach Aussagen von Zend) keine Performance-Verteile (auf Seiten von PHP) - im Gegenteil (Siehe Whitepaper unten).

Zend muss seine Produkte verkaufen...

was hat das damit zu tun? Wüßte nicht dass Zend Webserver verkauft. Denen kann es doch prinzipiell egal sein auf welcher Plattform die mit der eigenen IDE entwickelten Scripte laufen, oder in welchem Webserver jetzt deren ZPS... verwendet wird. Kann Dein Argument nicht nachvollziehen.

Ganz einfach: Würdest Du Dir die ZPS kaufen, wenn Du wüsstest, dass Du mit worker+mod_php das gleiche Ergebnis ereichst?

NPTL.

Gut, das kann sein. Aber verwendest Du die schon? In einem 2.6er Kernel?

Ja, seit ~2 Jahren.

Wenn Du keine besonders hohe Last hast, dann mal folgendes Zitat von Rasmus Posting aus php.internals (s.o.):

http://www.gaiaonline.com/forum/ wird derzeit von ~50 Servern serviert, nicht von einem. Eventuell sollte R.L. sich mal wieder in die Realität begeben? Ansonsten ein recht nettes Zitat, danke..

Wie meinst Du das? Rasmus arbeitet für Yahoo an der mit Abstand größten PHP-Installation der Welt: http://talks.php.net/show/lt2004-lamp/1 , und auch einige andere der Devs arbeiten an sehr großen Installationen, oder für große Provider.

I know. R.L. weiss allerdings auch, dass sich xxx.000.000.000.000 komplexere Scriptaufrufe nicht mit einem PHP-Interpreter bewältigen lassen.

Das alles gefährdet man durch den Einsatz von multithreaded Webservern.

Nein, die Gefahr geht nicht von multithreaded Webservern, sondern von unerfahrenen Administratoren,

Du meinst die die sich nicht drum kümmern wenn die Devs da hinschreiben "experimentell - DONT USE!!!!" ?

Ja, solange sie sich nicht ausreichend über den wirklichen Status sowie die möglichen Risiken/Vorteile der jeweiligen Extension informiert haben.

BTW: Wer garantiert Dir, dass eine als stable gekennzeichnete Core/Extension auch wirklich stable ist?

*SCNR*

sowie leichtsinnigen (siehe oben) beziehungsweise unfähigen Programmierern aus.

Wenn ich ein Programm vor langer Zeit geschrieben habe und einfach nicht für Threads vorgesehen habe - bin ich dann unfähig? Aus heutiger Sicht sagt sich sowas leicht.

Nö, bist Du nicht. Aber wenn ich Deinen Source ungeprüft in meiner als threadsafe gekennzeichneten Software verwende, bin ich nicht nur leichtsinnig, sondern auch unfähig.

Gruss,
Joe User

[andreask2]

Hoi!

Einigen wir uns auf Dokumentation? ;)

nein ;-)
Wir meinten 2 verschiedene Stellen, an der die Du meinst steht das schon lange, der Abschnitt in den FAQ eben erst seit einigen Monaten, basierend auf einem aktuellen Posting von R.L.. Aber auch egal :)

Nur weil viele Admins noch immer "Never change a runnung system." praktizieren, soll die Zuverlässigkeit von Apache2 noch öfter unter Beweis gestellt werden?

Die Sache ist ja die dass Apache 1.3 noch gepflegt wird, sich bewährt hat, und für die meisten Leute sicher vollkommen ausreicht. So ist es in meinen Augen nur verständlich dies zu empfehlen, eben weil es sich so gut bewährt hat. Ich selber würde aber inzwischen auch bedenkenlos Apache2-prefork einsetzen.
Nochmal aus dem Posting vom 17.06.2004:

Code: Select all

Well, how confident are you that the prefork mpm doesn't leak memory for
example?  There was a flood of messages about serious memory leaks on the
Apache dev list just today, for example, and that was just for static
requests, never mind more complex dynamic ones.

Aber wie gesagt - die Mehrheit der PHP-Devs sieht selbst das noch anders! Auch heute noch.

Nochmal aus der INSTALL (Stand 05.12.2004):

Code: Select all

     PHP and Apache 2.0.x compatibility notes: The following versions of
     PHP are known to work with the most recent version of Apache 2.0.x:

     * PHP 4.3.0 or later available at http://www.php.net/downloads.php.
     * the latest stable development version. Get the source code
       http://snaps.php.net/php4-latest.tar.gz or download binaries for
       Windows http://snaps.php.net/win32/php4-win32-latest.zip.
     * a prerelease version downloadable from http://qa.php.net/.
     * you have always the option to obtain PHP through anonymous CVS.

     These versions of PHP are compatible to Apache 2.0.40 and later.

     Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 works
     with Apache 2.0.39, don't use any other version of Apache with PHP
     4.2.3. However, the recommended setup is to use PHP 4.3.0 or later
     with the most recent version of Apache2.

Letzter Satz...

Ja und? Da steht - wohl gemerkt im Kapitel

Code: Select all

Apache 2.0 on Unix systems

This section contains notes and hints specific to Apache 2.0 installs
of PHP on Unix systems.

- dass in diesem Fall möglichst die neuste Version des Apache2 und mindestens PHP 4.3.0 zu verwenden ist. Ja und? Im selben Kapitel steht direkt hinter dem Titel und 2 Sätze vor den von Dir zitierten (CVS-Head):

Code: Select all

Warning

Do not use Apache 2.0.x and PHP in a production environment neither on
Unix nor on Windows. For information on why, read the following FAQ
entry

Du kannst das ja gerne mal auf php.internals zur Sprache bringen, die werden sich freuen ;-)

Deswegen steht in der Anleitung, in den FAQ, in den Kommentaren bei ./configure --help... dass man es doch bitte lassen soll, dass es experiemtnell ist und dass man mit Sicherheit Probleme bekommt.

Wenn Du jede dieser "Warnungen" beachtest, bleibt Dir nichteinmal mehr 20% der Funktionalität von PHP erhalten.

Sicher vor allem die alten XML-Extensions waren ja nie stabil. Aber das war auch Murks, dessen API hatte sich zwischendurch geändert, das war alles nicht so toll. Daher wurden auch große Teile davon komplett neu geschrieben. Inzwischen ist die neue DOM-Extension z.B. ja auch stabil gekennzeichnet. Aber sonst ist mir das eher selten aufgefallen, zumindest nicht bei wichtigen Extensions. Wenn da steht "experimentell" hat das meist so seinen Grund, es ist nicht immer nur eine veraltete Doku. Möglicherweise betrifft einen das Problem bzgl. experimentell auch gar nicht aber prinzipiell höre ich doch schon da drauf was dort steht.

Zumal es effizientere Ansätze gibt als einen multithreaded (bzw. hybriden, weil auch multi-prozess) Webserver zu verwenden.

Wozu stellt man sich ein Multiprozessor/HT-System als Webserver ins Rack, wenn man dann eh nur einen Prozessor nutzen kann?

Um am Beispiel von lighttpd zu bleiben - dieser hat dann x PHP-Prozesse die per fcgi angesprochen werden, die sich auf die Prozessoren verteilen. Andere Leute lassen auch Datenbanken oder andere Software auf demselben Server laufen. Große PHP-Installationen verwenden eh zig "Pizzaschachteln" in denen meist eh keine SMP-Systeme steckten.

ohne PIC

Aus sicherheitstechnischen Aspekten nicht zu empfehlen.

nicht? Evtl. gibt es das schon demnächst als ./configure switch (http://marc.theaimsgroup.com/?l=php-dev ... 701153&w=2) implementiert werden und es soll angeblich hierdurch genau so schnell sein wie statisch kompiliert (http://ilia.ws/archives/28-PHPApache-Static-vs-DSO.html) - wo ist hier sicherheitstechnisch das Problem?

Ganz einfach: Würdest Du Dir die ZPS kaufen, wenn Du wüsstest, dass Du mit worker+mod_php das gleiche Ergebnis ereichst?

Das hast Du auch gemessen? Naja, Opcode-Caches bringen auch nur was bei sehr komplexen Scripten unter sehr hocher Last. Abgesehen davon verwende ich PECL::APC ;-)
Opcode-Caches bringen aber auch in multithreaded Webservern Vorteile, mir wäre nicht bekannt dass das Worker MPM auch PHP-Scripte "ausführbar" im RAM hält ;-)

NPTL.

Gut, das kann sein. Aber verwendest Du die schon? In einem 2.6er Kernel?

Ja, seit ~2 Jahren.

Verwendest Du denn den 2.4er oder schon den 2.6er? Ich hab da immer noch so meine Bedenken wenn da mit jedem Release inzwischen das Changelog mal eben 1 MB überschreitet ;-)

I know. R.L. weiss allerdings auch, dass sich xxx.000.000.000.000 komplexere Scriptaufrufe nicht mit einem PHP-Interpreter bewältigen lassen.

Sollte ihm bekannt sein, ja ;-) Aber genau deswegen sagt er ja auch dass unter hoher Last die Zuverlässigkeit der Plattform das wichtigste ist. Und dann stellt man eben noch ein paar Pizzaschachteln dazu, ist erheblich billiger als multithreding-Probleme zu debuggen.

sowie leichtsinnigen (siehe oben) beziehungsweise unfähigen Programmierern aus.

Wenn ich ein Programm vor langer Zeit geschrieben habe und einfach nicht für Threads vorgesehen habe - bin ich dann unfähig? Aus heutiger Sicht sagt sich sowas leicht.

Nö, bist Du nicht. Aber wenn ich Deinen Source ungeprüft in meiner als threadsafe gekennzeichneten Software verwende, bin ich nicht nur leichtsinnig, sondern auch unfähig.

Noch ein kleines Zitat aus http://marc.theaimsgroup.com/?l=php-dev ... 021355&w=2

Code: Select all

PHP is glue.  It is the glue we use to build cool web applications by
sticking dozens of 3rd-party libraries together and making it all appear
as one coherent entity through an intuitive and easy to learn language
interface.  The flexibility and power of PHP relies on the stability and
robustness of the underlying platform.  We need a working OS, a working
web server and working 3rd-party libraries to glue together.  When any of
these stop working we need ways to identify the problems and fix them
quickly.  By making the underlying framework more complex by not having
completely separate execution threads, completely separate memory segments
and a strong sandbox for each request to play in, we introduce feet of
clay into our system.

Grüße,
Andreas

PS: http://dict.leo.org/?search=glue :)

[Joe User]

Moin,

Nochmal aus dem Posting vom 17.06.2004:

Code: Select all

Well, how confident are you that the prefork mpm doesn't leak memory for
example?  There was a flood of messages about serious memory leaks on the
Apache dev list just today, for example, and that was just for static
requests, never mind more complex dynamic ones.

Memory leaks sind glücklicherweise nicht Apache2 spezifisch.

Aber wie gesagt - die Mehrheit der PHP-Devs sieht selbst das noch anders! Auch heute noch.

Nochmal aus der INSTALL (Stand 05.12.2004):[snip]

Ja und?

Wenn es die Mehrzahl der PHP-Devs wirklich anders sehen würde, gäbe es die von mir zitierte Passage nicht, zumindest nicht in dieser Form.

Im selben Kapitel steht direkt hinter dem Titel und 2 Sätze vor den von Dir zitierten (CVS-Head):

Code: Select all

Warning

Do not use Apache 2.0.x and PHP in a production environment neither on
Unix nor on Windows. For information on why, read the following FAQ
entry

Irgendwie fehlt das why ;)

Du kannst das ja gerne mal auf php.internals zur Sprache bringen, die werden sich freuen ;-)

Sie würden sich freuen und die INSTALL kürzer ;)

Deswegen steht in der Anleitung, in den FAQ, in den Kommentaren bei ./configure --help... dass man es doch bitte lassen soll, dass es experiemtnell ist und dass man mit Sicherheit Probleme bekommt.

Wenn Du jede dieser "Warnungen" beachtest, bleibt Dir nichteinmal mehr 20% der Funktionalität von PHP erhalten.

Sicher vor allem die alten XML-Extensions waren ja nie stabil. Aber das war auch Murks, dessen API hatte sich zwischendurch geändert, das war alles nicht so toll. Daher wurden auch große Teile davon komplett neu geschrieben. Inzwischen ist die neue DOM-Extension z.B. ja auch stabil gekennzeichnet. Aber sonst ist mir das eher selten aufgefallen, zumindest nicht bei wichtigen Extensions. Wenn da steht "experimentell" hat das meist so seinen Grund, es ist nicht immer nur eine veraltete Doku. Möglicherweise betrifft einen das Problem bzgl. experimentell auch gar nicht aber prinzipiell höre ich doch schon da drauf was dort steht.

Seit wann nutzt Du PECL/PEAR (XML-Extension)? *SCNR*

ohne PIC

Aus sicherheitstechnischen Aspekten nicht zu empfehlen.

nicht? Evtl. gibt es das schon demnächst als ./configure switch (http://marc.theaimsgroup.com/?l=php-dev ... 701153&w=2) implementiert werden und es soll angeblich hierdurch genau so schnell sein wie statisch kompiliert (http://ilia.ws/archives/28-PHPApache-Static-vs-DSO.html) - wo ist hier sicherheitstechnisch das Problem?

If you are using the gentoo hardened toolchain, typically compiling your programs will create PIC ELF libraries that do not contain text relocations. However, certain libraries still contain text relocations for various reasons (often ones that contain assembly that is handled incorrectly). This can be a security vulnerability as an attacker can use non-PIC libraries to execute his shellcode. Non-PIC libraries are also bad for memory consumption as they defeat the code sharing purpose of shared libraries.

To disable this error and allow your program to run, you must sacrifice security and allow runtime code generation for that program. The PaX feature that allows you to do that is called MPROTECT. You must disable MPROTECT on whatever executable is using the non-PIC library.

Note: To check your system for textrels, you can use the program check-textrel that solar has written for that purpose located in his development space: http://dev.gentoo.org/~solar/pax/misc/check-textrel.

Sollte Dir als (Hardened-)Gentoo-User bekannt sein ;)

Ganz einfach: Würdest Du Dir die ZPS kaufen, wenn Du wüsstest, dass Du mit worker+mod_php das gleiche Ergebnis ereichst?

Das hast Du auch gemessen?

Nein, ich kaufe keine überteuerte (Closed-Source) Software.

Naja, Opcode-Caches bringen auch nur was bei sehr komplexen Scripten unter sehr hocher Last. Abgesehen davon verwende ich PECL::APC ;-)
Opcode-Caches bringen aber auch in multithreaded Webservern Vorteile, mir wäre nicht bekannt dass das Worker MPM auch PHP-Scripte "ausführbar" im RAM hält ;-)

OK, den Opcode-Cache der ZPS habe ich vergessen:
s/worker+mod_php/worker+mod_php+APC/

NPTL.

Gut, das kann sein. Aber verwendest Du die schon? In einem 2.6er Kernel?

Ja, seit ~2 Jahren.

Verwendest Du denn den 2.4er oder schon den 2.6er?

Aktuell setze ich ausschliesslich 2.6+NPTL ein, hatte aber auch schon 2.[45]+NPTL im Einsatz.

I know. R.L. weiss allerdings auch, dass sich xxx.000.000.000.000 komplexere Scriptaufrufe nicht mit einem PHP-Interpreter bewältigen lassen.

Sollte ihm bekannt sein, ja ;-) Aber genau deswegen sagt er ja auch dass unter hoher Last die Zuverlässigkeit der Plattform das wichtigste ist. Und dann stellt man eben noch ein paar Pizzaschachteln dazu, ist erheblich billiger als multithreding-Probleme zu debuggen.
[snip]

"Ich geh mal Pizzen holen, das Produkt reift ja beim Kunden..."

Gruss,
Joe User

[andreask2]

Moin!

Memory leaks sind glücklicherweise nicht Apache2 spezifisch.

Nein, aber sind ein Zeichen dafür wie ausgereift die Software ist.

Wenn es die Mehrzahl der PHP-Devs wirklich anders sehen würde, gäbe es die von mir zitierte Passage nicht, zumindest nicht in dieser Form.

Da steht doch lediglich: FALLS Du Apache2 verwenden willst - obwohl davon dringend abgeraten wird, da Apache2-Unterstützung experimentell - wird empfohlen mindestens PHP 4.3.0 zusammen mit der neusten Apache2 Version zu verwenden. Nenn mir nur einen Grund warum sich was an der Auffassung aus dem Posting von vor wenigen Monaten geändert haben soll. Aber speziell für Dich, nochmal alles im zeitlichen Ablauf ;-):

Das was Du zitiert hast stand vor der INSTALL bereits in der Apache2-Installationsanleitung:

Code: Select all

However, the recommended setup is to use PHP 4.3.0 or later with the most recent version of Apache2.

04.06.2004: http://cvs.php.net/co.php/phpdoc/en/ins ... .xml?r=1.1

Danach kam das Posting von Rasmus auf php.internals:

Code: Select all

I have explained this a number of time, but here we go again...

16.06.2004: http://marc.theaimsgroup.com/?l=php-dev ... 021355&w=2

Am selben Tag wird das noch in die Apache2 - Anleitung aufgenommen: http://cvs.php.net/co.php/phpdoc/en/ins ... .xml?r=1.2

Ebenfalls am selben Tag wurde es dann an seinen endgültigen Bestimmungsort in die FAQ verlagert und aus der Apache2-Anleitung verlinkt: http://cvs.php.net/co.php/phpdoc/en/faq ... xml?r=1.29

Am 10.08.2004 wurde dann schließlich auch die INSTALL-Datei an die Installations-Anleitungen im Netz abgepasst: http://cvs.php.net/co.php/php-src/INSTALL?r=1.34.2.1

Aber gut - jeder muss selbst wissen was er für Software einsetzt, in den meisten Szenarien spricht IMHO nicht viel gegen Apache2-Prefork, ich persönlich würde eben das Worker-MPM nicht zusammen mit mod_php einsetzen. In Kombination mit CGI/FCGI ist das natürlich was anderes, kommt für mich im Moment aber nicht in Frage.

Im selben Kapitel steht direkt hinter dem Titel und 2 Sätze vor den von Dir zitierten (CVS-Head):

Code: Select all

Warning

Do not use Apache 2.0.x and PHP in a production environment neither on
Unix nor on Windows. For information on why, read the following FAQ
entry

Irgendwie fehlt das why ;)

Siehe Manual: http://de3.php.net/manual/en/install.unix.apache2.php =>

Warning

Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows. For information on why, read the following FAQ entry

=> http://de3.php.net/manual/en/faq.instal ... on.apache2

Du kannst das ja gerne mal auf php.internals zur Sprache bringen, die werden sich freuen ;-)

Sie würden sich freuen und die INSTALL kürzer ;)

Ich meine das ernst, oder schreib nen Bug-Report! Ich kann Dir auch schon die Antwort vorhersagen:

RTFM: http://de3.php.net/manual/en/faq.instal ... on.apache2 ;-)

Seit wann nutzt Du PECL/PEAR (XML-Extension)? *SCNR*

;-)
Also DOMXML, SAX... und ja, ich nutze einige PEAR/PECL Extensions (HTTP*, DB*, XML*, MAIL*, CACHE*, APC, memcache, xdebug...)

If you are using the gentoo hardened toolchain, typically compiling your programs will create PIC ELF libraries that do not contain text relocations. However, certain libraries still contain text relocations for various reasons (often ones that contain assembly that is handled incorrectly). This can be a security vulnerability as an attacker can use non-PIC libraries to execute his shellcode. Non-PIC libraries are also bad for memory consumption as they defeat the code sharing purpose of shared libraries.

To disable this error and allow your program to run, you must sacrifice security and allow runtime code generation for that program. The PaX feature that allows you to do that is called MPROTECT. You must disable MPROTECT on whatever executable is using the non-PIC library.

Note: To check your system for textrels, you can use the program check-textrel that solar has written for that purpose located in his development space: http://dev.gentoo.org/~solar/pax/misc/check-textrel.

Sollte Dir als (Hardened-)Gentoo-User bekannt sein ;)

Interessant, danke! Ich bin allerdings noch kein Hardened-User :). Ich verwende bisher nur grsec-sources, bei hardened, habe ich bei meiner letzten Installation noch etwas Angst vor Instabilitäten oder sonst irgendwelchen Problemen gehabt. Hälst Du hardened für den produktiven Einsatz geeignet - bzw. setzt Du das ein?
Allerdings verstehe ich den Text nicht 100%ig. Was soll das heißen "er kann non-PIC Libs verwenden um seinen Shellcode auszuführen"? Wodurch wird er hier in die Lage versetzt eigenen Shellcode auszuführen? Ich meine, mann kann doch prinzipiell in jeder Software mit passendem Buffer-Overflow eigenen Shellcode ausführen, ob jetzt mit PIC oder ohne. Kann der hier lokal etwas erreichen? Aber ohne Root kann er ja solche Libs nicht manipulieren, also was ist jetzt das Problem?
non-PIC heißt doch ganz grob einfach, dass keine shared libs verwendet werden, sondern dass sich diese binaries entsprechende Libs selber und nur für sich in den Speicher laden, oder?

Ganz einfach: Würdest Du Dir die ZPS kaufen, wenn Du wüsstest, dass Du mit worker+mod_php das gleiche Ergebnis ereichst?

Das hast Du auch gemessen?

Nein, ich kaufe keine überteuerte (Closed-Source) Software.

Kannst Du ja kostenlos testen - daran soll es nicht scheitern :)
Abgesehen davon gibt es genügend freie Produkte die ähnlich schnell sind oder sogar schneller.

"Ich geh mal Pizzen holen, das Produkt reift ja beim Kunden..."

Bon appétit ;-)

Grüße
Andreas

[andreask2]

Hallo Joe!

Wenn es die Mehrzahl der PHP-Devs wirklich anders sehen würde, gäbe es die von mir zitierte Passage nicht, zumindest nicht in dieser Form.

Ich weiß nicht ob es eine Mehrheit gegen Apache2-Prefork gibt (womit ich auch kein Problem habe), das ist umstritten. Aber ich kenne keinen Dev, der Apache2-Worker empfiehlt.

Zur Zeit findet auf php.internals wieder eine Diskussion zum Thema statt, wenn es Dich interessiert kannst Du ja mal mitlesen, oder was dazu sagen!

Ausgangsposting von Sebastian Bergmann (20.12.): news://news.php.net:119/cq6n64$cgb$1@sea.gmane.org
(oder z.B. hier: http://www.zend.com/lists/php-dev/20041 ... html#00160 - nicht ganz so aktuell)

Viele Grüße
Andreas

[andreask2]

Hallo!

Zur Zeit findet auf php.internals wieder eine Diskussion zum Thema statt, wenn es Dich interessiert kannst Du ja mal mitlesen, oder was dazu sagen!

Ausgangsposting von Sebastian Bergmann (20.12.): news://news.php.net:119/cq6n64$cgb$1@sea.gmane.org
(oder z.B. hier: http://www.zend.com/lists/php-dev/20041 ... html#00160 - nicht ganz so aktuell)

Die durch die Postings von Rich Bowen (apache.org) angestoßene Diskussion hat tatsächlich was gebracht, und zwar wird die Dokumentation in den nächsten Tagen wie folgt geändert:

Code: Select all

We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the following FAQ entry

Quelle: http://livedocs.phpdoc.info/index.php?l ... ix.apache2

Code: Select all

 Why shouldn't I use Apache2 with a threaded MPM in a production environment?
PHP is glue. It is the glue used to build cool web applications by sticking dozens of 3rd-party libraries together and making it all appear as one coherent entity through an intuitive and easy to learn language interface. The flexibility and power of PHP relies on the stability and robustness of the underlying platform. It needs a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working PHP needs ways to identify the problems and fix them quickly. When you make the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, feet of clay are introduced into PHP's system.

If you feel you have to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space.
And finally, this warning against using a threaded MPM is not as strong for Windows systems because most libraries on that platform tend to be threadsafe.

Quelle: http://livedocs.phpdoc.info/index.php?l ... on.apache2

Das Thema wurde unter anderem auch von /. aufgegriffen, genau so von diversen Blogs.

Hier nochmal "brandaktuelle" Aussagen einiger PHP-Devs zum Thema, ich denke hier sollte deutlich werden dass es nur um Apache1 vs. Apache2-prefork geht, von anderen MPMs, vor allem Multithreding wird mehrfach abgeraten, die Neuerung an der Doku spiegelt das Resultat der aktuellen Diskussion:

I am very happy to hear many people say that PHP and Apache 2 works for them, I wrote a fair bit of code in Apache 2 SAPIs :-). But, the fact it works for some does not mean it works for all and the reports I see on PHP's bug system clearly demonstrate Ap2/PHP is not yet on par with Ap1/PHP.

- no static modules
- no proven reliability

The Apache 2 SAPI is not stable or tested as is Apache 1 dso/static sapis.
In time this will change, but meanwhile the docs advise caution.

OpenSource being what it is (e.g.: "get your finger out"), it seems to
me like we will get stable Apache 2 support when someone knowledgeable
in the Apache 2 guts sits down and does the work.

We don't have any resident Apache 2 experts (e.g.: we've established
that 1.3 works fine for us in our busy professional lives), and the
two Apache guys that offered to do the work haven't been around lately.

When enough people want the apache2 sapi to be production quality,
then eventually someone will become interested enough to do the work.

Threading will never be fixed in the large hundreds of
3rd-party library sense. So there is nothing to fix there. The only
question is whether we start recommending Apache2-prefork over Apache1.
As far as I am concerned we start doing that when a majority of main PHP
developers switch to Apache2-prefork. Personally I am completely
unmotivated to make that change because I have a boatload of other modules
written against the Apache1 API that I would need to port to Apache2 and
there just isn't a killer feature in Apache2 that warrants doing all that
work for me at this point and Apache1 works fine. There isn't that much
for a web server to do. We just need a simple working server.


If I am in the minority I don't mind suggesting people use Apache2, but we
need a bunch of PHP developers to stand up and say they are using
Apache2-prefork in large production systems. It has never been a matter
of not liking Apache2 or having some irrational bias against it, it is
purely a matter of what we use and what we know. If someone reports a
problem with PHP running under Apache1 we know how to fix that. For other
servers, including Apache2, the pool of people familiar enough with it to
provide decent support is much smaller. The documentation should probably
be changed to better reflect that and make it sound less negative towards
Apache2.

The warning and FAQ entry was written quite a while ago. I have updated it now to just talk about threading issues and that people should stick to the prefork MPM, at least on Unix systems.

I've got to say that I have seen quite a few very heavily loaded sites using Apache 2 pre-fork and PHP. Although we have had a few bugs in the past few months in the Apache 2 SAPI I think it's quite stable today, and some of those bugs wouldn't have affected many people. It's definitely getting a lot of testing and many Linux distros are bundling Apache 2 and PHP.

Personally, I think we can drop the experimental from Apache 2 pre-fork+PHP and have a warning about using the other MPMs.
I don't think we have to officially recommend any one version of Apache (we can say it works with both). Personally, I do still prefer Apache 1.3.x but the main reason is because I'm used to it and can't be bothered to move, not because I think Apache 2 is not stable.

I made the change in the phpdoc/en tree. I hadn't realized before that
someone had taken one of my mailing list emails and pasted it almost
directly into the FAQ in the documentation.

The changes should trickle out with the next manual build. I don't think
it was a big deal before, and making a big deal of it now probably doesn't
help anybody. It's not like we suddenly fixed a bunch of things in the
apache2handler sapi and we only have a vague idea that it is stable.

My own tests which are a bit dated (few months old) show that there is no performance difference between Ap1 and Ap2 (prefork mpm) so why bother switching? In fact when PHP is compiled statically into Ap1 it becomes a lot faster (thanks to no-pic) then dynamically loaded module in Ap2.

The compression available in Ap1 via mod_gzip is sorta replaced by the built-in mod_deflate, but it is not as configurable.
The PHP support for Ap1 sapi is very mature, while Ap2 is relatively new with two competing sapis (Although it seems that most use apache2handler now), which is not as stable then Ap1 still.

So, I entreat the PHP folks to remove this incorrect anti-Apache 2.0 tirade from their documentation, and replace it with a more balanced and correct explanation of the issues involved, and the recommended solution. Namely, that people go ahead and move to Apache 2.0, but stick with a Prefork MPM. This gives them most of the benefits of Apache 2.0, but removes the irritating threading issues. Nobody blames PHP for those threading issues (at least, people who have taken the trouble to actually understand the issue donâ??t), so thereâ??s no slight on the PHP developers implied here.

Why would we (as PHP developers) invest time in something while the
current version provides us with all we need?

Redhat also shipped beta GCC with their distro which caused enumerable number of problems. Just because they choose to distribute something does not mean it's production quality code.

Viele Grüße
Andreas

[andreask2]

Hello again ;-)

Ein kleiner Artikel zum Thema "Apache 1 vs Apache 2 Performance" von Ilia:
http://ilia.ws/archives/32-Apache-1-vs- ... mance.html

Grüße
Andreas

PS: Die Ã?nderungen am PHP-Manual bzgl. PHP+Apache2 sind übrigens online: http://www.php.net/manual/en/install.unix.apache2.php (siehe "Warning" und FAQ-Link)