vBulletin 4 & PHP 7 - drastic speed improvement!

[Dave]

Refer to my blog post in case you want to make vBulletin 4 work on PHP 7 as well:
https://blog.technidev.com/vbulletin-4-and-php-7-making-it-work/

-----

http://www.zend.com/en/resources/php-6-need-to-know-about-php-7

So PHP 7 has been released and it offers significant new features, including drastic speed changes (2 times faster according to Zend!).

As expected, PHP 7 doesn't work with vBulletin 4. The main reason is because of "methods with the same name as their class will not be constructors in a future version of PHP" and a couple of other things. So for example, the class vB_Database may not have a method name called vB_Database that's used as a constructor.

Since I have the latest vBulletin 4 version installed and I don't expect any new version of vBulletin 4 anytime soon, I'll probably give it a shot and modify my forum to see if I can make it work with PHP 7.

I will definitely document the speed changes and let you guys know the results.
Anyone else who may be interested in this?

--------------- Added 1449314753 at 1449314753 ---------------

After a couple of modifications, I managed to make vBulletin 4 work with PHP 7... and wow it loads so much faster. More than 2 times faster with PHP 7 and the OPCache module... wow. My mind is blown.

Note that all the numbers below are based on the TTFB (Time To First Byte).

Before the upgrade (PHP 5.4.45)
Homepage
409.31 - 429.84 - 389.37 - 401.51 - 389.75 - 426.69
~407.75ms average loading time

Forum Category
518.51 - 491.49 - 447.64 - 491.94 - 433.52 - 543.93
~487.84ms average loading time

Thread
326.34 - 399.72 - 387.09 - 383.79 - 370.03 - 375.21
~373.70ms average loading time

-----

After the upgrade (PHP 7 WITHOUT OPCache)
Homepage
289.79 - 291.41 - 289.11 - 253.45 - 285.06 - 259.98
~278.13ms average loading time

Forum Category
281.83 - 333.31 - 293.23 - 276.73 - 268.91 - 281.63
~289.27ms average loading time

Thread
221.73 - 344.83 - 257.84 - 250.72 - 250.04 - 220.07
~257.53ms average loading time

-----

After the upgrade (PHP 7 WITH OPCache)
Homepage
225.63 - 200.26 - 219.48 - 181.72 - 199.93 - 177.55
~200.76ms average loading time

Forum Category
194.95 - 184.47 - 237.45 - 182.62 - 185.93 - 178.06
~193.91ms average loading time

Thread
207.83 - 156.41 - 146.43 - 143.13 - 155.13 - 142.61
~158.59ms average loading time

https://vborg.vbsupport.ru/external/2015/12/34.png

[RichieBoy67]

Interesting. What did you have to do to make your site compatible?

[Dave]

On top of my head, I had to make changes to the following files:

includes/class_core.php (to fix constructor error)
includes/class_datastore.php (to fix constructor error)
includes/class_bbcode.php (to fix function name must be a string error)
includes/class_hook.php (to fix constructor error)
vb/exception/parser.php (to fix redefinition of argument error)

Also I had to change the datastore class in config.php back to vB_Datastore_Filecache since there's no PHP 7 version for APC/XCache or Memcached. You don't need it anymore anyway since OPCache has been introduced and it's extremely fast.

Another thing to keep in mind is that PHP 7 deprecates the mysql_* functions. In case you have any plugins or custom scripts installed which makes use of that then it will not work.

[Elite_360_]

Since I have the latest vBulletin 4 version installed and I don't expect any new version of vBulletin 4 anytime soon

VB 4.2.4 beta 1 is coming out soon you should report the bug, and maybe it will be in VB 4.2.4

[Dave]

VB 4.2.4 beta 1 is coming out soon you should report the bug, and maybe it will be in VB 4.2.4

I've seen a ticket for the error in vb/exception/parser.php.
I don't know how the other changes I've made affect earlier versions of PHP, so not sure if they want to bother "fixing" that since they officially don't even support PHP 7.

[Paul M]

I've seen a ticket for the error in vb/exception/parser.php.
I don't know how the other changes I've made affect earlier versions of PHP, so not sure if they want to bother "fixing" that since they officially don't even support PHP 7.
The parser error was logged and fixed for php7 (by me) in vB5, I dont think its been logged for vB4 (or 3).

There is a Jira for vB4 php7 support, but thats about as far as its got atm (other than I have some test sites running).

[Max Taxable]

Performance about average, nothing amazing here. Assuming the site in your signature is the subject site. My sites perform significantly better.

http://www.webpagetest.org/result/151208_83_1K5H/

[Dave]

Performance about average, nothing amazing here. Assuming the site in your signature is the subject site. My sites perform significantly better.

http://www.webpagetest.org/result/151208_83_1K5H/

No, it's not. It's just a very basic PHP site (not related to vBulletin).
I get an average TTFB of 20ms on that site.

--

The location of the test server at webpagetest.org affects the final result by a lot, which is why you can't use that as a reliable tool to find out how fast a site is unless you test it from America, Asia and Europe and compare the results.

Also if I compare my own results in Chrome's developer tools with the results of webpagetest.org, it doesn't match.
If I clear my browser and DNS cache, the first load of https://technidev.com (located in Amsterdam) takes 1.50 seconds, yet webpagetest.org (Amsterdam server) states 5 seconds.

[Max Taxable]

The location of the test server at webpagetest.org affects the final result by a lot, which is why you can't use that as a reliable tool to find out how fast a site is unless you test it from America, Asia and Europe and compare the results.It's just real browsers with real connections, not servers at all. It's volunteer real-world computers, and the location really doesn't matter that much but the connection sure does. I test everything with one set of parameters, I don't test-shop. I optimize to worst case, not to what I might get on my own computer - that's not objective.

Care to provide a link to this super fast php7 vB4?

[Max Taxable]

I'm not trying to be a snark, I just see claims of millisecond load speeds and want to see that put to a real test. I've never seen millisecond load speeds.

[Dave]

I'm talking about TTFB, not complete page load. (Which is also what I stated in my first post in case you didn't see that.)

http://www.webpagetest.org/result/151208_TR_1KFJ/

Keep in mind that PHP only affects the TTFB. As you can see, it matches the results I posted in my first post.
The forum itself uses quite some images and other third party resources so it's not the fastest when it comes to the complete page load.

[Max Taxable]

(Which is also what I stated in my first post in case you didn't see that.)Is this after your edit? Because I sure don't recall seeing anything about FBT.
webpagetest.org/ result/151208_TR_1KFJ/I don't test using Chrome, because by design and to give the false illusion of being "faster" it ignores certain types of calls. I always test worst case, which is IE11.

http://www.webpagetest.org/result/151208_3G_1M6Y/

FBT is nebulous, and depends on many factors. For example, if you use Cloud Flare (which you are) it is proven to greatly slow FBT. There's many other variables involved including just good old fashioned response of the host server at different times and load conditions.

You deliver 73 requests and 1.4 megabytes. 9 seconds for that isn't murder.

[Dave]

We're going completely off-topic though, you are talking about the complete page load while I'm talking about the time it takes for PHP to process the request.

If you don't believe that PHP 7 makes vBulletin fast (so that is vBulletin's server side processing), then that's fine. I highly recommend you to try it out yourself though.

However when it does come to the complete page load, I rather rely on my own findings instead of a "reliable" web page testing service.

[Max Taxable]

We're going completely off-topic though, you are talking about the complete page load while I'm talking about the time it takes for PHP to process the request.

If you don't believe that PHP 7 makes vBulletin fast (so that is vBulletin's server side processing), then that's fine. I highly recommend you to try it out yourself though.I neither believe it nor disbelieve it. If you believe it that's fine with me. I merely choose to work on full seconds reduction, than tiny milliseconds. I could take at least 5 seconds off your full load time with only about 30 minutes work.

However when it does come to the complete page load, I rather rely on my own findings instead of a "reliable" web page testing service.A "reliable" one that's not trying to sell you anything, and is designed, operated and maintained by Google's tech chief, Patrick Meenan. And is the only objective real-world real-browser real-connection optimization standard out there.

Seconds count, not milliseconds. Bang for the buck - your time is worth something.

Congrats though on getting v4 up to the new PHP standard, that's good work but it doesn't help page load time significantly. And certainly not drastically.

[Dave]

It does help page response time significantly, if you refuse to believe that then there's nothing much I have to say. Also a handful of my users reported to me that they noticed a big difference.

I guess you'll see more posts of users regarding the speed difference in the future when they start to migrate to PHP 7. ;)

[Max Taxable]

It does help page response time significantly, if you refuse to believe that then there's nothing much I have to say. Also a handful of my users reported to me that they noticed a big difference.

I guess you'll see more posts of users regarding the speed difference in the future when they start to migrate to PHP 7. ;)Right. Milliseconds noticeable by the everyday user who wasn't told to look for drastic improvement. Prompted beforehand or not, that's all subjective, and there is no way milliseconds can be drastic or a big difference. That's why they are milliseconds.

I'm just skeptical, I hope that is okay with you just like your belief is okay with me. The test I ran and posted though, you had a pretty poor FBT on that one.

[Dave]

You will indeed not notice a difference if we're talking about a few milliseconds, however a few hundred milliseconds is definitely noticeable. In my case, the server is twice as fast to process the PHP request and return a response ever since I upgraded.

[final kaoss]

Anyways, aside from Max trying to derail the topic... I'm not to familiar on updating php, I'm using centos & want to update it to php 7. Can you write or send me to an article about that?

Oh and max, here you go, page loads in the milliseconds (under a second).
https://gtmetrix.com/reports/www.odysseyofhyrule.com/EvicPyGk
And note, I'm not trying to make this a discussion about that report. Just responding to a post of yours on page 1.

[Dave]

Have you looked at my article at https://blog.technidev.com/vbulletin-4-and-php-7-making-it-work/ ?
It includes a URL on how to upgrade to PHP 7 and how to fix the errors in order to make it work.

[Alan_SP]

Excellent thread, I just wanted to ask if someone already has some experience with PHP7, as I read about it being out: http://php.net/archive/2015.php#id2015-12-03-1

On those who have Plesk servers (servers that use Plesk CP v12.5), it is supported with microupdate 14: http://docs.plesk.com/release-notes/12.5/change-log/#12530-mu14 On this last news, it appears that there's a bug in Plesk that linux versions still don't have PHP7, but it soon will be there.

From my experience, changing PHP version in Plesk, if you use Plesk's own system for multiple PHP versions is extremely easy. Just go to website settings and there you choose which PHP version you want for that website. It works excellent.

On the other hand, as @Paul M mentioned, vB4.2.4 still doesn't have PHP7 support, but it would be great if we ask for it, as it is still possible. And, vB4.2.4 will be out in foreseeable future.

Here is Jira about that issue: http://tracker.vbulletin.com/browse/VBIV-16127

Please help having official support for PHP7 in vB4.2.4

And @Dave, for some reason I can't open your site and blog with your experience and instruction for PHP7 and vB4. Is it only temporary?

[Dave]

@Alan_SP
My blog works fine from here, weird.
Here's the post with the upgrade instructions: http://pastie.org/pastes/10622659/text?key=2i6pp4sxtqlc7ktv3mwxg

[Alan_SP]

Thanks for the info, I just tested it with FireFox, it seems you're blocking my browser (Opera). Probably same as was with Ozzmodz (http://ozzmodz.com/showthread.php/533-Site-doesn-t-work-with-old-Opera-(maybe-other-older-browsers-too)).

[HolyKiller]

Hello all,

first of all thank you for the blog post. We're about to migrate our web services to PHP 7 as well and vB forum is one of them. I've done the modification as mentioned unfortunately i am facing an issue when posting a new thread/post. It will end up in blank post.

New thread with some text
https://vborg.vbsupport.ru/external/2016/07/4.png (https://postimg.org/image/kymiw7yrr/)

This is how it looks like after submit
https://vborg.vbsupport.ru/external/2016/07/5.png (https://postimg.org/image/i39fpcurr/)

Firebug confirms that no text at all in the body
https://vborg.vbsupport.ru/external/2016/07/6.png (https://postimg.org/image/5n84hvc1z/)

I've tested it with all plugins disabled via "define('DISABLE_HOOKS', true);" and with the default template as well. Still facing the issue.

We're running following setup in our test environment:
vBulletin 4.2.2 Patch Level 5
PHP Version 7.0.8
Web server: fpm-fcgi

I've also found following warnings in error.log ... not sure if related or just another things to be fixed.

PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP;
vB_DataManager has a deprecated constructor in /www/includes/class_dm.php on line 20
vB_DataManager_Multiple has a deprecated constructor in /www/includes/class_dm.php on line 1628
vB_DataManager_ThreadPost has a deprecated constructor in /www/includes/class_dm_threadpost.php on line 27
vB_DataManager_Post has a deprecated constructor in /www/includes/class_dm_threadpost.php on line 656
vB_DataManager_Thread has a deprecated constructor in /www/includes/class_dm_threadpost.php on line 1031
vB_DataManager_Thread_FirstPost has a deprecated constructor in /www/includes/class_dm_threadpost.php on line 1574
vB_BbCodeParser_Wysiwyg has a deprecated constructor in /www/includes/class_bbcode_alt.php on line 28
vB_BbCodeParser_ImgCheck has a deprecated constructor in /www/includes/class_bbcode_alt.php on line 689
vB_BbCodeParser_PrintableThread has a deprecated constructor in /www/includes/class_bbcode_alt.php on line 846
vB_BbCodeParser_PlainText has a deprecated constructor in /www/includes/class_bbcode_alt.php on line 890
vB_BbCodeParser_Video_PreParse has a deprecated constructor in /www/includes/class_bbcode_alt.php on line 1618
vB_DataManager_Forum has a deprecated constructor in /www/includes/class_dm_forum.php on line 37
vB_DataManager_User has a deprecated constructor in /www/includes/class_dm_user.php on line 31
vB_Postbit has a deprecated constructor in /www/includes/class_postbit.php on line 176
vB_DataManager_IP_Data has a deprecated constructor in /www/includes/class_dm_ip_data.php on line 29
vB_DataManager_Content_Read has a deprecated constructor in /www/includes/class_dm_content_read.php on line 29

Thanks in advance for any advice.

Alex

[Paul M]

See this : https://vborg.vbsupport.ru/showthread.php?t=322892

(Btw, two of the fixes in that blog are not actually correct).

[webmastersun]

On top of my head, I had to make changes to the following files:

includes/class_core.php (to fix constructor error)
includes/class_datastore.php (to fix constructor error)
includes/class_bbcode.php (to fix function name must be a string error)
includes/class_hook.php (to fix constructor error)
vb/exception/parser.php (to fix redefinition of argument error)

Also I had to change the datastore class in config.php back to vB_Datastore_Filecache since there's no PHP 7 version for APC/XCache or Memcached. You don't need it anymore anyway since OPCache has been introduced and it's extremely fast.

Another thing to keep in mind is that PHP 7 deprecates the mysql_* functions. In case you have any plugins or custom scripts installed which makes use of that then it will not work.

You should send these to vB team so we can use PHP7 on forums earilier

I want to upgrade to PHP7 for my hosting but I could not because my vB forum is not compatible with PHP7 so I have to leave it.

[Dave]

See this : https://vborg.vbsupport.ru/showthread.php?t=322892

(Btw, two of the fixes in that blog are not actually correct).

I'll probably write a follow up blog for more changes/fixes for PHP 7.
Although you state that some of the fixes are not "correct", my forum has been running just fine for about 8 months now on PHP 7.

[Paul M]

You should send these to vB team so we can use PHP7 on forums earilier

I want to upgrade to PHP7 for my hosting but I could not because my vB forum is not compatible with PHP7 so I have to leave it.

Did you even bother to read the link I posted ?

I'll probably write a follow up blog for more changes/fixes for PHP 7.
Although you state that some of the fixes are not "correct", my forum has been running just fine for about 8 months now on PHP 7.
Actually, I said two, not some ;)

One you would never notice unless you somehow triggered exceptions, even then it would probably just display wrong information.
The other would, I think, break something (custom tags ?) I'm not actually anywhere I can look at code atm.

If they were the only changes you made, you are hiding a ton load of warnings.

The PHP 7 test version has been available for anyone who requests it for almost two months now, posted here, vb.com, and even TAZ - only three people have shown any interest. The Alpha's next month will basically be that code.

[Domenico]

I love vB 4.2.5 Beta 1 and together with PHP7 it runs perfectly.

[Dave]

I love vB 4.2.5 Beta 1 and together with PHP7 it runs perfectly.

Are you running it with PHP7.1 or PHP 7.0.*?
PHP 7.1 should speed it up by a tiny bit more.

[RichieBoy67]

I have the beta as well and would love to upgrade but I think I would have to go through older plug ins and I know my Photopost gallery would have issues as well.

I may do it though at some point.

[z3r0]

I've updated two of my sites to 4.2.5b1 and PHP7 over the last two days, it's been a pain fumbling though the plugins fixing them with my limited understanding of PHP, but the speed increase has been well worth it.

I do have a few scripts flagging with depreciated constructor errors, but everything is running and I can try and figure them out at a later date.

[Paul M]

Fortunately, when they released 7.1.x they kept the stuff deprecated in 7.0.x (like constructors) rather than removing them. Had they removed them, it would have been real chaos.

Instead they decided to make other changes (for example, around performing mathamatical operations on strings) which is causing a few problems (much harder to detect as well).

JFYI, the next 3.8.11 & 4.2.5 Beta releases should be later this month.