Originally Posted by Randy Petersen

Managing a high volume Web site has a unique challenge when you consider all the moving parts. Our latest problem turned out to be related to this:
Performance Hit Since PHP 4.3.10 / 5.0.3
Many people have noticed that vBulletin (and a lot of other PHP applications) suddenly started to run significantly slowed than normal after installing PHP 4.3.10 or 5.0.3 in order to patch the security flaw in previous versions of PHP.
This cause of this slow-down has been identified as a problem with the unserialize() function in PHP. For more details, see bugs.php.net.
This problem has now been fixed by the PHP developers, though the fixed version has yet to be released in a 'stable' version. However, the latest CVS snapshots of PHP 4.3.x and 5.0.x, available from snaps.php.net contain the fix and restore the original speed of unserialize().
While we would not recommend running a 'dev' version of PHP on any production server, we understand that the performance problem has been a major issue for some people. If you are badly affected, you may want to consider running a 'dev' version of PHP at your own risk in order to overcome the performance problem.

As it turns out, when we moved to this latest version of PHP to fix a potential security flaw, it caused the slow down (and as noted, not just for our Web site). We are currently awaiting the official release fo the new version with the fix not opting to go with the 'dev' version because there are risks associated with that and we really are not interested in becoming a statistic. Once this fix is released, we'll install, test and reopen search. etc.

Thanks for being patient as well as understanding there are a lot of moving parts on this Web site and we're not just talking about our members. HA!

Originally Posted by Rut Dog

thanks

Originally Posted by John at Webflyer

Actually the question needs to be asked of the developers of PHP.

vBulletin doesn't have much to do with it.

The new release could come at any time.

Originally Posted by alanw

What exactly is a milepost? :confused:

Originally Posted by John at Webflyer

Different boards use different techniques -- one of the largest boards in the world limits the number of connections -- if you hit that board during peak hours chances are good that you'll be locked out. That's definitely something we don't want to do.

Originally Posted by Kremmen

It'd be a hell of a lot better than no search.

Originally Posted by serfty

I have been involved with IT for many years and generally people prefer restricted/slow access to no access on an 'ad hoc' basis.

Originally Posted by Kremmen

I've been involved in IT for many years too, and I'd agree that people prefer slow access to no access, which is why we should have search even if it slows the board down, rather than no search, which amounts, in many respects, to no access.

What amazes me is that there are so many options to get around this, but none are being employed here: patch php, patch vbulletin, use the php fix issued on Jan 16 (see the bottom of the php bug discussion), go back to a previous version (was there any real risk from the bug anyway? can the risk be circumvented by reducing some less important piece of functionality?), etc.

By far the simplest thing to do, if there is any real risk of the latest php versions being unstable (which seems unlikely), would be to run a new version of php in parallel with the current site. www.flyertalk.com could have the current setup, unusable but stable, while ww2.flyertalk.com (or whatever) could have the latest vbulletin and latest php.

Originally Posted by Kremmen

It'd be a hell of a lot better than no search.

Originally Posted by John at Webflyer

And if there was a security problem in the cvs snapshot that led to the board being pwned and the database damaged, possibly emptied? How would you react to that?

Originally Posted by Kremmen

I'd say that the day lost in restoring from backup would be vastly less of a pain than the lack of FT functionality so far.

However, if you think that's a real risk, why not just patch 4.3.10 with the performance fix, if you don't want to risk taking onboard all the other changes in any CVS snapshot?

I do wonder though whether it even mattered. Okay, there were some bugs in PHP 4.3.9. Could they actually be triggered by vbulletin? If so, were any particular circumstances required? The only reports I've seen have been very superficial -- PHP had bugs, vbulletin uses PHP, therefore upgrade PHP -- and may have been an overreaction in the first place. It's amazing to me that vbulletin are being so useless in an area they should know intimately.