Hallo,
also irgendwie ist mir das bei Debian immer noch nicht klar. Ich geh mal von einem normalen .configure bei z.Bsp php 5, selbst kompiliert aus. Ich habe vorher alle Abhängigkeiten mit "apt-get ..." aufgelöst, die Liste war recht unproblematisch zu finden:
# apt get source php5.1
aus der Dexter Quelle genommen und dort zu finden in der entpackten source unter "/home/test/php4.4-4.4.2/debian/packages" unter (z. Bsp.)
# --with-pgsql
Build-Depends: postgresql-dev (>= 7.2-4)
So jetzt bin ich bei .configure. Sagen wir mal ich schließe dabei folgendes ein:
#--with-zip
Ich habe aber vorher die "libzzip-dev" mit apt-get installiert. Muss ich jetzt das dir "/usr" unbedingt angeben?
Weil eigentlich doch nicht. In der info.php findet er nämlich entsprechendes auch ohne dir.
Aber warum steht bei "/home/test/php4.4-4.4.2/debian/packages" siehe oben!, das so da?
--with-zip=shared,/usr
Ist das jetzt nur wegen "shared" ? Weil ich dachte debian, bzw. php findet zip automatisch, wenn es in der entsprechenden dir "/usr" ist und vorher im Standardpfad mit apt-get installiert worden ist?
Dann noch eine Frage am Rande. Ist es jetzt besser alles "shared" zu machen, oder besser die Bibliotheken statisch einkompilieren, wobei natürlich die Grösse des php-binary auf unsägliche 20 MB anwächst ( mit allen Funktionen, statisch einkompiliert.
gruß cirox
php extensions dirs und shared oder statisch linken
Re: php extensions dirs und shared oder statisch linken
Damit hast Du Deine Frage eigentlich schon selbst beantwortet - ein 20 MB großes Binary ist schlicht und ergreifend inakzeptabel. Wenn Du einen Server dediziert nur für eine bestimmte Site zur Verfügung hast (z. B. einen Online-Shop, ein CMS o. ä.) macht es Sinn, nur genau die benötigten Module statisch einzukompilieren und auf dynamische Module zu verzichten. Das spart den Overhead des Modul-Managements und bringt somit etwas Performance.cirox wrote:Dann noch eine Frage am Rande. Ist es jetzt besser alles "shared" zu machen, oder besser die Bibliotheken statisch einkompilieren, wobei natürlich die Grösse des php-binary auf unsägliche 20 MB anwächst ( mit allen Funktionen, statisch einkompiliert.
In einem Shared-Hosting-Szenario braucht jeder Kunde andere PHP-Module. Wenn mit FastCGI realisiert, können die PHP/FastCGI-Prozesse und Threads für die einzelnen Sites dank eigener php.ini mit genau den benötigten Modulen ausstaffiert werden - das klappt aber nur, wenn diese eben als dynamische Module vorliegen und nicht statisch gelinkt sind (es sei denn, Du kompilierst für jeden User sein eigenes PHP-Binary, aber da wird's dann irgendwann krank...)
Re: php extensions dirs und shared oder statisch linken
Hallo,
ok, das heisst doch aber mit anderen Worten, ich setzt also beim komilieren überall ein "Shared" dahinter, wo es angebracht ist, mit dem jeweiligen dir, wo es der Kompiler nicht von alleine findet.
Ich muss dann aber jedes einzelne Modul (... .so) in der php.ini für alle oder entsprechend laden?
Weil so beim statischen linken braucht man das ja nicht. Und dann wäre ja da noch das Problem mit dem openbasedir. Also wenn ich "Shared" sage muss ich ja wohl auch im openbasedir den Pfad angeben. Nun befinden sich meine Libarys, da mit debian über apt-get installiert, grössenteils unter "/usr". Da muss man ja glatt /usr/ freigeben, hm.....
Vielleicht bring ich da ja auch noch was durcheinander. Ist es vielleicht so dass meine Module, die ich lade, in meinem php Verzeichnis, also dort wo ich reinkompiliert habe liegen und ich Sie , wenn bei "./configure" "shared" angegeben wurde, dynamisch aus eben diesem Verzeichnis laden kann? Und nur die Biblitheken, die diese Module brauchen halt im System sind, aber das gar nicht smit den ladbaren Modulen als solches zu tun hat, sondern nur dass diese Module eben halt gewisse Libarys noch benötigen ?
gruss cirox
ok, das heisst doch aber mit anderen Worten, ich setzt also beim komilieren überall ein "Shared" dahinter, wo es angebracht ist, mit dem jeweiligen dir, wo es der Kompiler nicht von alleine findet.
Ich muss dann aber jedes einzelne Modul (... .so) in der php.ini für alle oder entsprechend laden?
Weil so beim statischen linken braucht man das ja nicht. Und dann wäre ja da noch das Problem mit dem openbasedir. Also wenn ich "Shared" sage muss ich ja wohl auch im openbasedir den Pfad angeben. Nun befinden sich meine Libarys, da mit debian über apt-get installiert, grössenteils unter "/usr". Da muss man ja glatt /usr/ freigeben, hm.....
Vielleicht bring ich da ja auch noch was durcheinander. Ist es vielleicht so dass meine Module, die ich lade, in meinem php Verzeichnis, also dort wo ich reinkompiliert habe liegen und ich Sie , wenn bei "./configure" "shared" angegeben wurde, dynamisch aus eben diesem Verzeichnis laden kann? Und nur die Biblitheken, die diese Module brauchen halt im System sind, aber das gar nicht smit den ladbaren Modulen als solches zu tun hat, sondern nur dass diese Module eben halt gewisse Libarys noch benötigen ?
gruss cirox
Re: php extensions dirs und shared oder statisch linken
Das Verzeichnis, in dem die Module liegen, braucht nicht im open_basedir zu liegen (das ist sogar ausgesprochen gefährlich!). Es genügt, wenn die Benutzer, unter denen die PHP/FastCGI-Prozesse gestartet werden, Lese-/Ausführungsberechtigung (r-x oder 5) für dieses Verzeichnis haben.
Wenn Du auf FastCGI setzt, werden doch für alle VHosts ein PHP/FastCGI-Prozess und mehrere Kindprozesse mit dem PHP-Binary gestartet. Wenn Du Dir die Mühe machst, für jeden VHost eine eigene php.ini einzurichten, brauchst Du also für jeden VHost nur die Module (dynamisch) laden, die auch benötigt werden (anstatt für jeden vhost alle Module statisch einzukompilieren). In Summe sparst Du also einiges an Arbeitsspeicher.
Ein simples Beispiel: Auf meiner Maschine laufen momentan 5 virtuelle Hosts. Für jeden wird ein PHP/FastCGI-Elternprozess und 9 Kindprozesse gespawnt. Würde jeder der Prozesse mit einem 20MB-Binary erzeugt, wäre der Speicherbedarf allein für PHP
5 * 10 * 20 = 1000 MB
Ok, mein PHP-Binary ist keine 20 MB groß... und nicht jede Site ist so stark frequentiert, dass man mehr als 4 Kindprozesse benötigt. Daher die Empfehlung, bei einer Shared-Hosting Umgebung mit unterschiedlichen Anforderungen an PHP aus den virtuellen Hosts lieber nicht die eierlegende Wollmilchsau zu bauen, sondern lieber bedarfsorientiert mit dynamischen Modulen arbeiten.
Alternativ ließe sich in einer FastCGI-Umgebung auch für jeden virtuellen Host ein eigene (statisch kompilierte) PHP-Binary bauen. Theoretisch ist das die performanteste und eleganteste Lösung, da der Overhead für das Laden der Module wegfällt. Allerdings ist das ein ziemlicher Aufwand, wenn man dann mal PHP updaten will... (zumindest wenn man mehr als 2-3 virtuelle Hosts hat)
Wenn Du auf FastCGI setzt, werden doch für alle VHosts ein PHP/FastCGI-Prozess und mehrere Kindprozesse mit dem PHP-Binary gestartet. Wenn Du Dir die Mühe machst, für jeden VHost eine eigene php.ini einzurichten, brauchst Du also für jeden VHost nur die Module (dynamisch) laden, die auch benötigt werden (anstatt für jeden vhost alle Module statisch einzukompilieren). In Summe sparst Du also einiges an Arbeitsspeicher.
Ein simples Beispiel: Auf meiner Maschine laufen momentan 5 virtuelle Hosts. Für jeden wird ein PHP/FastCGI-Elternprozess und 9 Kindprozesse gespawnt. Würde jeder der Prozesse mit einem 20MB-Binary erzeugt, wäre der Speicherbedarf allein für PHP
5 * 10 * 20 = 1000 MB
Ok, mein PHP-Binary ist keine 20 MB groß... und nicht jede Site ist so stark frequentiert, dass man mehr als 4 Kindprozesse benötigt. Daher die Empfehlung, bei einer Shared-Hosting Umgebung mit unterschiedlichen Anforderungen an PHP aus den virtuellen Hosts lieber nicht die eierlegende Wollmilchsau zu bauen, sondern lieber bedarfsorientiert mit dynamischen Modulen arbeiten.
Alternativ ließe sich in einer FastCGI-Umgebung auch für jeden virtuellen Host ein eigene (statisch kompilierte) PHP-Binary bauen. Theoretisch ist das die performanteste und eleganteste Lösung, da der Overhead für das Laden der Module wegfällt. Allerdings ist das ein ziemlicher Aufwand, wenn man dann mal PHP updaten will... (zumindest wenn man mehr als 2-3 virtuelle Hosts hat)
Re: php extensions dirs und shared oder statisch linken
Hallo,
verstehe, also kurz um, die Extensions mit "shared" kompilieren, bei denen es möglich ist und in der php.ini die entprechenden .... .so Module laden?
Soweit ich das jetzt verstanden habe funktioniert das mit shared im Gegensatz zu statisch linken so, dass er sich die Libarys aus dem System holt und beim statischen Linken die kompletten Module ins binary packt. Also muss es ja so funktionieren, dass bei (./configure --with imap=shared,/usr) alles wie gehabt funktioniert. Ich muss bloss noch die ..so Datei in der php.ini laden?
gruß cirox
verstehe, also kurz um, die Extensions mit "shared" kompilieren, bei denen es möglich ist und in der php.ini die entprechenden .... .so Module laden?
Soweit ich das jetzt verstanden habe funktioniert das mit shared im Gegensatz zu statisch linken so, dass er sich die Libarys aus dem System holt und beim statischen Linken die kompletten Module ins binary packt. Also muss es ja so funktionieren, dass bei (./configure --with imap=shared,/usr) alles wie gehabt funktioniert. Ich muss bloss noch die ..so Datei in der php.ini laden?
gruß cirox
Re: php extensions dirs und shared oder statisch linken
AFAIK sollte das so sein.
Re: php extensions dirs und shared oder statisch linken
Hallo,
ok ich hab jetzt alles mögliche mit "shared" kompiliert, natürlich nur was shared sein soll, hoffe ich, und dann auch noch das extension_dir in der php.ini angepasst
auf das extension Directory unterhalb von meinem kompilierten php, soweit so gut, aber mein php4_binary hat leider immer noch 8 MB, geht das nicht noch kleiner?
mein ./configure:
gruß cirox
ok ich hab jetzt alles mögliche mit "shared" kompiliert, natürlich nur was shared sein soll, hoffe ich, und dann auch noch das extension_dir in der php.ini angepasst
Code: Select all
extension_dir = /home/user/pfad_zu_php/lib/php/extensions/no-debug-non-zts-20020429mein ./configure:
Code: Select all
./configure
--prefix=/home/user/pfad_zu_php
--enable-force-cgi-redirect
--enable-fastcgi
--disable-rpath
--enable-magic-quotes
--with-openssl
--with-kerberos
--with-pcre-regex
--with-zlib
--enable-bcmath=shared
--with-bz2=shared,/usr
--enable-calendar=shared
--with-curl=shared,/usr
--enable-dba=shared
--with-gdbm=/usr
--with-db4
--with-cdb=/usr
--with-inifile
--with-flatfile
--enable-exif=shared
--enable-ftp=shared
--with-gd=shared
--with-jpeg-dir=shared,/usr
--with-png-dir=shared,/usr
--with-zlib-dir=shared,/usr
--with-xpm-dir=shared,/usr/X11R6
--with-ttf=shared,/usr
--with-freetype-dir=shared,/usr
--with-t1lib=/usr
--enable-gd-native-ttf
--with-gettext=shared,/usr
--with-gmp=shared,/usr
--with-iconv
--with-imap=shared,/usr
--with-imap-ssl
--enable-mbstring
--with-libmbfl
--with-mcrypt=shared,/usr
--with-openssl-dir
--with-mhash=shared,/usr
--with-mime-magic=shared,/usr/share/misc/file/magic.mime
--with-mysql=shared,/usr
--with-ncurses=shared,/usr
--with-pspell=shared,/usr
--enable-shmop=shared
--enable-sockets=shared
--enable-sysvsem=shared
--enable-sysvshm=shared
--enable-sysvmsg=shared
--enable-wddx=shared
--with-expat-dir=/usr
--with-xmlrpc
--with-iconv-dir
--with-zip=shared,/usr
--enable-memory-limit
--without-mm
--enable-filepro=shared
--with-crack=shared,/usr
--with-cyrus=shared,/usr
--enable-dbx=shared
--with-dom=shared,/usr
--with-dom-xslt=/usr
--with-dom-exslt=/usr
--with-mcal=shared,/usr
--enable-xslt=shared
--with-xslt-sablot=/usr
Re: php extensions dirs und shared oder statisch linken
alles was mit -with anfängt wird das binary größer machen.. hast Du danach mal mit
strip -s phpbinary die Debug Symbole und Co rausgeschmissen?
strip -s phpbinary die Debug Symbole und Co rausgeschmissen?
Re: php extensions dirs und shared oder statisch linken
Hallo,
ah, danke, jetzt sinds nur noch 2,8 MB nach dem strip, geht ja langsam.
gruß cirox
ah, danke, jetzt sinds nur noch 2,8 MB nach dem strip, geht ja langsam.
gruß cirox