compiling php > slow vbulletin

[nowrap]

hello!
if i compile php on an upgraded rh9 > fc3 box. vbulletin is terrible slow. page render times from 16s and more. if i use a before selfcompiled php rpm vbulletin runs fine. page render times under 1s.

how can this be?
thats really really strange ;(

which components are needed for compiling. maybe i manually replace them all. the box is updated with yum.

.nowrap

[eva2000]

got a link to your phpinfo.php url ? what version of php ? if 4.3.10 ensure you have Zend Optimizer 2.5.7 if you have an older version of Zend Optimizer

[nowrap]

the link:
http://80.190.250.124/info.php

i compiled php 4.3.10 from fedora 3 srpm and php 5.0.3 from php.net sources.
a compiled 5.0.2 srpm works fine. that one was compiled before the upgrade.
no zend installed right now. using eaccellerator 0.92 but deactivated for debugging.

right now i installed dbg in order to profile which part is causing the delay, if i can figure out how to use it ;(


and i want to update to 4.3.10 or 5.0.3 cause of the security issues (and vb 3.0.5 if available as german version)


can the problem be based on the autoconf, automake and libtool versions?


// edit
all other php scripts just work fine, like phpmyadmin. so it isn't php itself, maybe just a module or function within ??!

[Zachery]

You might not want to configure with ever option possible.

[nowrap]

yes i know, i just get rid of the stuff not needed. this i will do from home.

// edit
changed the configure options for compiling and kept only needed php extensions/functions.
but vbulletin is still far to slow ;(

[eva2000]

so 5.03 slow only ? or 4.3.10 slow too ? i'd stick with 4.3.10 as it could be issues with 5.03 and vB until vBdevs give 5.0.3 the official okay anyway

[nowrap]

both version run slow ... actually i think, every new self compiled version runs slow.

right now i ordered the nusphere phped and check the index.php with the profiler, to get a clue, where the lack comes from.

i keep you informed

// edit
maybe one of the damn hacks kills vb? how can i get rid of them all. even after upgrading, they are present and i copied the complete upload folder!
(there are 2 admins, 1 of them likes hacks *buax*)

[Zachery]

If you downloaded a fresh zip file and used thoughs files, there are no hacks installed.

[nowrap]

sure! i got the vb3.0.4 zip from vb-germany. deflated it locally and copied the complete upload folder via sftp. than run the upgrade procedure and overwrote every file on the server!

// edit
vb 3.0.5 de is ready ;)

updated and cleaned from hacks (but only with the 5.0.2 rpm version)
with 5.0.3 it is still slow ... damn, the dbg module for 4.3.10 or 5.0.3 is not available right now

[nowrap]

okay, here the update.
php via yum remove php deinstalled
vb 5.0.3 de fresh without hacks installed (updated DB)

php 5.0.2 with minium extensions (gd, ldap, snmp, mysql) from source.tar.gz compiled. forum works fine and fast
profiler session for index.php:
3 slowest scripts are
includes/init.php
includes/functions.php
includes/db_mysql.php

slowest function with 300ms is
init.php@587 $forumcache = unserialize($storeitem['data']);

now i will try this with php 5.0.3

// edit
php 5.0.3 compiled from source.tar.gz is still terribly slow ;(
profiler not yet available. contacted nusphere support
same configure settings as with 5.0.2

now i will try this with php 4.3.10

// edit
php 4.3.10 compiled from source.tar.gz is still terribly slow ;(
profiler not yet available. contacted nusphere support
same configure settings as with 5.0.2

now i will try this with php 4.3.9

// edit
php 4.3.9 runs fine ... damn .... !!!
i will continue tomorrow, hopefully having the new dbg.so to figure out which part of vb causes the delay.

[nowrap]

one possible idea, maybe the problem is related with the unserialize function of the forumcache ... ? this part took the longest period of time concerning the profiler.

php 5 changelog
Fixed potential problems with unserializing invalid serialize data. (Marcus)

php 4 changelog
Fixed potential problems with unserializing invalid serialize data.


what is this cache? where is it stored? can it be resetted/rebuild?

[nowrap]

finally i got the new dgb.so files from the nusphere support. i look forward to do the profiling to get some light in this weird behaviour.

[nowrap]

so, i got php 4.3.10 up with the new debugging.so file and started profiling the forum index.

includes/init.php line 587 takes 17s !!!
$forumcache = unserialize($storeitem['data']);

with php 4.3.9 it only takes 0.3s ... the big price is why this happens ... the serialize and unserialize functions were adjusted due to security issues.

is this a php bug? a vbulletin problem? or just damn accidentally ;(
but it isn't the build system actually

help?

[nowrap]

i emptied the forumcache in the datastore table *g* (backuped it before)
now it runs fast but i got an error ... can i rebuild the cache?

okay found it
Admin CP -> Import & Maintenance -> Update Counters -> Rebuild Forum Information

or use the tools.php from the do-not-upload folder *G*

[nowrap]

but this doesn't solve the speed problem ... hopefully you have some ideas about this cache unserialize behaviour

// note
the cache is 2.27 MB big

[nowrap]

i googled a bit and found this:
http://bugs.php.net/bug.php?id=31332

so, it is a known php bug.

the options i have:
- stay with 4.3.9
- disable the cache

[eva2000]

i googled a bit and found this:
http://bugs.php.net/bug.php?id=31332

so, it is a known php bug.

the options i have:
- stay with 4.3.9
- disable the cache
hmm.. maybe try hardened-php 4.3.9 which has patched the fixes for 4.3.10 to remain secure ?

[nowrap]

with hardened php 4.3.9 the board works fine. but the nusphere debugger and the zend optimizer aren't compatible ;(

zend doesn't matter coz of the eaccelerator but the debugger ;(

[eva2000]

with hardened php 4.3.9 the board works fine. but the nusphere debugger and the zend optimizer aren't compatible ;(

zend doesn't matter coz of the eaccelerator but the debugger ;(
:( can't help ya with nusphere debugger sorry maybe contact hardened-php folks ?

[nowrap]

dimitri from nusphere compiled a version, which i am now testing and will be put in their package afterwards ;)

// edit
forum runs fine so far ... only 2 minor problems, i post in the right places

can be closed this thread, hope i could help others with it!

[kmike]

Wow. And I thought I did something wrong when upgrading to 4.0.10. This sucks.
Going to recompile latest RHEL3 version of php (4.3.2-ent), as it does have 4.0.10's security fixes.

I wonder why more people do not stumble into this? Shouldn't this thread be made sticky?

[nowrap]

@kmike
you can use 4.3.9 with the hardened patch, runs really fine on my box.

kier from vB also confirmed this issue on bugs.php.net. but a sticky post or a good official announcement would be great ;)

[Robbban]

I run FC3 also and have high loads up to 90-150 (!!!)... Had RH9 before and installed FC3...

[nowrap]

@robban
this maybe doesn't relate to this problem described by me. as we tracked down the issue to php 4.3.10/5.0.3

hardened php 4.3.9
sadly i must report, that hardened php is also no option ;(
editing large templates (greater 10kb) under admincp results in empty templates. switched back to 4.3.9 until the php guys fix the slowdown.

[nowrap]

maybe i should read better ;)

The behavior of Hardened-PHP's variable filter can be modified from
within php.ini. There are currently 4 directives that control several
aspects of variable filtering:

varfilter.max_request_variables (default: 200) - The maximum number of
variables that can be passed per request
varfilter.max_varname_length (default: 64) - Maximum length for a
variable name
varfilter.max_value_length (default: 10000) - Maximum length for a
variable value.
varfilter.max_array_depth (default: 100) - Maximum depth of an Array.

[eva2000]

so what value did you set them to for vB ? or you back on 4.3.9 regular ?

[nowrap]

here are my settings that work with hardenend php:

Directive Local Value Master Value
varfilter.max_array_depth 200 200
varfilter.max_request_variables 500 500
varfilter.max_value_length 100000 100000
varfilter.max_varname_length 64 64

i adjusted max_request_variables (needed for the css admincp pages) and max_value_length (needed for the template editing).

[MacMorag]

This thread really should be stickied.

I have just upgraded from 4.3.9 to 4.3.10 - and am now stuck in molasses!

Luckily, I found this thread - so now I can see that rather than a simple choice between security (4.3.10) and speed (4.3.9), there is a third option - 4.3.9 hardened.

My question: So far I have only ever used CPanel/WHM to upgrade software on my ded server. Hardened 4.3.9 is not an option doing it this way. How do I upgrade (downgrade????) to 4.3.9 hardened? I have root access.

Thanks for any help/instructions/pointers.

[nowrap]

one thing i want to mention about hardened php. the zend optimizer isn't compatible with hardenend php !!! for speeding up php, use an other accelaretor like eaccelerator (turck mm cache) or apc.
if u need the optimizer for running zend encoded files, hardenend php is no option for you.


if u've root access:
1. get the configure setting from the phpinfo();
2. download php 4.3.9 sources
3. extract them
4. download hardnend php patch
5. extract them, too
6. apply the hardened php patch
7. use the configure settings from step 1
8. make
9. make install
10. restart apache

that should do it, or? ;)
it's always a good thing to make a backup of the php.ini and the httpd.conf !

[alkooheji]

According to php bug site (http://bugs.php.net/bug.php?id=31332)


[15 Jan 11:27pm CET] gik at zap dot cl I've compiled the latest snapshot of PHP_4_3 and it seems to be behavingmuch better on real-life applications (I haven't tried the test programattached to this thread yet). I'll keep testing for a few more days tobe sure the server's performance has returned to normal levels. Thanks for the prompt reaction.


does this mean that the problem is soleved with php 4.3.10 ?

[nowrap]

nope, it's solved in the snapshots from the cvs version of php 4.3.10
(it's the development to php 4.3.11)

[alkooheji]

I am more concerned about performance than security... and i upgraded pyp to 4.3.10. Now me and my members and vistors are really suffering from slow forum.. My members started leaving the forum to other faster ones.

Is it ok to revert back to php 4.3.9 ? because the hardened option really confused me..

vbTeam.. we are following your recommendation, please get us out of it asap with clear instructions

[nowrap]

if u don't care about security go back to 4.3.9.

hardenend php is just a patch to apply to the sources. u've to compile php on your own.

the fixed slowdown from the snapshots frpm 4.3.10 are development versions

[goha]

If it is fixed in php 4.3.11?
I just had it isntalled, and looks like i got this problem again.
I am running 3.0.6 with 07 patch.

Another question - if this is fixed for VB 3.5? If 3.5 is really faster? How it works with serialize?

[Zachery]

Goha, can you start your ownt hread and with your own details, please include the size of yoour forums, how many forums and usergroups you have, and your server specs. Thanks

[goha]

I put my question here, because I have faced this concrete problem year ago, and I know what is this probem about. It is not releatvie to forum size or settings, it is relative to PHP version and serialize/deserialize problem - as it is described in THIS thread.

My question - if the problem persists in php 3.3.11 and if this problem may appear in VB 3.5? Or VB 3.5 is aware of this problem and will be never affected with such a problem?

P.S.
Sure, I can open new thread, but it will be linked to this thread anyway, and i will need to retype half of this thread to explain the problem.

Please let me discuss it here.

P.P.S.
My forum is http://forums.goha.ru (according to my license).
300-600 ppls online simultaneously (15 min refresh time).
53 active user groups
Hundreds of forums and subforums.

[goha]

Guys, I need help
Please

I am in trouble..

[Steve Machol]

As Zach requested, please start your own thread with all the relevant information. Thank you.