nach php kompilieren ist vbulletin unerträglich langsam

[nowrap]

hallo!
ich nutze eine von redhat9 auf fedora core 3 aktualisierte maschine.
sowohl das übersetzen von php 4.3.10 via srpm als auch das manuelle kompilieren von php 5.0.3 führen dazu, dass vbulletin 3.0.4 (vorher 3.0.1) unerträglich langsam läuft.

mit dem selbstkompiliertem php 5.0.2 rpm (aus der redhat 9 zeit) liegen die seiten renderzeiten unter 1s. mit den neuen version bei 15s und mehr ;(

wie kann ich diese problem eingrenzen oder woran kann es liegen?
.nowrap

[cane]

Warum willst Du es denn selbst kompilieren und mit welchen Optinen hast Du kompiliert?

mfg
cane

[Tomek]

Ist das PHP-Errorlogging aktiviert? Steht irgendwas in dem Apache-Errorlog?

[nowrap]

die configure optionen sind die gleichen wie beim php 5.0.2 (stehen ja in der phpinfo();). allerdings sind die vom srpm recht umfangreich, da ja alle module als packete gebaut werden.

error logging ist aktiviert, da steht rein gar nix ... was an sich auch nicht verwunderlich ist, da es kein fehler gibt und das forum funktioniert, halt nur langsam.



'./configure' '--host=i686-redhat-linux-gnu' '--build=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=/usr/lib/php/modules' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-xml' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-pear=/usr/share/pear' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-mime-magic=/usr/share/file/magic.mime' '--without-sqlite' '--with-mysqli=/usr/bin/mysql_config' '--with-apxs2=/usr/sbin/apxs' '--with-mysql=shared,/usr' '--with-gd=shared' '--without-odbc' '--with-xmlrpc=shared' '--with-ncurses=shared' '--with-ldap=shared' '--enable-mbstring' '--with-snmp=shared'

[psy]

hallo!
ich nutze eine von redhat9 auf fedora core 3 aktualisierte maschine.
sowohl das übersetzen von php 4.3.10 via srpm als auch das manuelle kompilieren von php 5.0.3 führen dazu, dass vbulletin 3.0.4 (vorher 3.0.1) unerträglich langsam läuft.

mit dem selbstkompiliertem php 5.0.2 rpm (aus der redhat 9 zeit) liegen die seiten renderzeiten unter 1s. mit den neuen version bei 15s und mehr ;(

wie kann ich diese problem eingrenzen oder woran kann es liegen?
.nowrap
ich nehme mal an, dass du als datenbank "mysql" benutzt, hat sich da evtl. auch was geändert?

[nowrap]

vbulletin läuft nur mit mysql ;)
es läuft aktuell die 4.1.8 in der icc version ... aber dies und auch apache scheiden aus, da das forum mit den 5.0.2 rpms ganz normal läuft, ergo liegt es am php.

// edit
kann man den apache stracen?

weil nen
$strace /etc/init.d/httpd start
führt zu
execve("/etc/init.d/httpd", ["/etc/init.d/httpd", "start"], [/* 22 vars */]) = 0

was mir rein gar nix sagt ;(

[nowrap]

habe das problem mit dem profiler von nusphere profiler getrackt.

in php 4.3.10 und 5.0.3 wurden die serialize/unserialize funktionen aus sicherheitsgründen geändert. dies führt anscheinend zur verzögerung beim deserialisieren des vbulletin forencaches.

es liegt also nicht am build system von fedora.