phpBB 3.1 load

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.2.x. If you need support for phpBB 3.2.x please visit the 3.2.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
User avatar
Paul
Infrastructure Team Leader
Infrastructure Team Leader
Posts: 364
Joined: Thu Sep 16, 2004 9:02 am
Contact:

Re: phpBB 3.1 load

Post by Paul » Fri Nov 29, 2013 11:06 am

DoYouSpeakWak wrote:It doesnt really matter. Its slower, As confirmed here. viewtopic.php?f=81&t=43957#p251247. You can disable debug on your test board and compare the two versions if you like. Im sure you will come to the same conclusion.
I dont disagree that claiming phpBB3 is slower in DEBUG mode, there is proof enough for that. But I (as in, myself, not a developer/taemmember) dont care how fast it is in a test env. In a prod env, I do, but I havent seen proof for that it is slower there.

User avatar
JoshyPHP
Registered User
Posts: 360
Joined: Fri Jul 08, 2011 9:43 pm

Re: phpBB 3.1 load

Post by JoshyPHP » Fri Nov 29, 2013 11:29 am

It's really hard to give any reliable data about performance. (I assume that's what you meant, because CPU load is something different and dependent on other factors)

The best you can hope for is for someone to find the motivation to benchmark a few pages off a fresh install. That would be an estimation of how much overhead there is. It doesn't really tell anything about real-world performance though, because faking the data and the user activity is too complex to be done properly. To have more reliable numbers you'd need to measure the performance of an actual board such as this one.

Danielx64
Registered User
Posts: 304
Joined: Mon Feb 08, 2010 3:42 am

Re: phpBB 3.1 load

Post by Danielx64 » Fri Nov 29, 2013 11:47 am

JoshyPHP wrote:It's really hard to give any reliable data about performance. (I assume that's what you meant, because CPU load is something different and dependent on other factors)

The best you can hope for is for someone to find the motivation to benchmark a few pages off a fresh install. That would be an estimation of how much overhead there is. It doesn't really tell anything about real-world performance though, because faking the data and the user activity is too complex to be done properly. To have more reliable numbers you'd need to measure the performance of an actual board such as this one.
Yeah the reason why I brought that up is because some people may be on a system where they get x% of a cpu core and if they go over that the site will slow down (like trying to run windows 8 on a 500mhz cpu, it will run but be slow)

User avatar
JoshyPHP
Registered User
Posts: 360
Joined: Fri Jul 08, 2011 9:43 pm

Re: phpBB 3.1 load

Post by JoshyPHP » Sat Nov 30, 2013 4:07 pm

On the subject of performance, yesterday I looked into profiling the index page but I couldn't generate a meaningful call graph with Kcachegrind and xhprof insisted on segfaulting. Nevertheless, I could see that most of the time was spent in common.php (around 53% as I recall) and a lot of time was spent in Container#get() but I didn't dig deeper than that. The time spent in Container was an aggregate that includes the time spent in object constructors, it doesn't really mean anything.

What I did find though is that there were more than a hundred calls to Composer's autoloader. They resulted in some ~1400 calls to strpos() in Composer's ClassLoader#findFile, due in part to my having installed dev dependencies. I don't know what the plans are for the final release but I'd strongly recommend using Composer's namespace autoloader for the phpbb namespace and use a classmap for everything else. It would greatly reduce the number of misses in Composer.

I'll try to dig deeper and post some proper findings when I have some time. If someone else looks into profiling phpBB, learn from my mistakes and remember to uninstall dev dependencies.

User avatar
Noxwizard
Support Team Leader
Support Team Leader
Posts: 135
Joined: Sun Dec 18, 2005 5:44 pm
Location: Texas
Contact:

Re: phpBB 3.1 load

Post by Noxwizard » Sun Dec 01, 2013 8:05 pm

JoshyPHP wrote:On the subject of performance, yesterday I looked into profiling the index page but I couldn't generate a meaningful call graph with Kcachegrind and xhprof insisted on segfaulting.
This is one from xhprof: http://theexiled.pwnageservers.com/phpb ... lgraph.png
Top level stats for index.php: http://theexiled.pwnageservers.com/phpbb_tests/xhprof/
That was run on Alpha2 with a warm cache.

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: phpBB 3.1 load

Post by nickvergessen » Sun Dec 01, 2013 9:14 pm

Btw we also announce that the memory limit minimum is 16MB now, up from 8MB in 3.0
Member of the Development-TeamNo Support via PM

User avatar
JoshyPHP
Registered User
Posts: 360
Joined: Fri Jul 08, 2011 9:43 pm

Re: phpBB 3.1 load

Post by JoshyPHP » Tue Dec 03, 2013 7:27 am

Noxwizard wrote:This is one from xhprof: http://theexiled.pwnageservers.com/phpb ... lgraph.png
Top level stats for index.php: http://theexiled.pwnageservers.com/phpbb_tests/xhprof/
That was run on Alpha2 with a warm cache.
That's nice, thanks. What version of PHP and which opcode cache was that?

I'm not very familiar with phpBB internals or xhprof, but just looking at EWall% I see that the two places where it spent the most time was mysqli_query() and load::search/fulltext_native.php. mysqli_query() makes sense but I don't understand why loading fulltext_native.php took so long, or even why it was loaded on the index page for that matter. Are every cron tasks loaded on every page? It seems that they are and they cause a lot of files to be loaded.

Looking at the ECPU% column, the biggest spender is Composer\Autoload\ClassLoader::findFile() with 8.6%. Did you have the dev dependencies installed? That's a lot of time spent mapping class names to file names. That's mostly due to misses in Composer when it tries to load a phpbb* class, because it has to go through all the autoloaders registered for the dependencies before giving up. And with dozens of classes loaded for cron tasks and events, it ends up costing. I see that it's been called 167 times.

MaFeSa
Registered User
Posts: 69
Joined: Sun Aug 26, 2012 1:44 pm

Re: phpBB 3.1 load

Post by MaFeSa » Thu Mar 12, 2015 8:31 pm

Here seems that the use of the ram has decreased a lot!
First -> Peak Memory Usage: 9.5 MiB
Now -> Peak Memory Usage: 3.8 MiB

Will be so also in 3.1.4?

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: phpBB 3.1 load

Post by brunoais » Thu Mar 12, 2015 9:55 pm

phpBB 3.1 is slower than 3.0 but there's no real big difference for the most visited pages. The cache does a great job making sure all happens fast enough and repeated operations fall under the cache's reach.

User avatar
VSE
Extension Customisations
Extension Customisations
Posts: 670
Joined: Mon Mar 08, 2010 9:18 am

Re: phpBB 3.1 load

Post by VSE » Fri Mar 13, 2015 4:30 am

MaFeSa wrote:Here seems that the use of the ram has decreased a lot!
First -> Peak Memory Usage: 9.5 MiB
Now -> Peak Memory Usage: 3.8 MiB

Will be so also in 3.1.4?
It's probably because this site is using some sort of PHP cache on the server, such as APC, OPcache or XCache. Such things really improve its performance back to the 3.0 specs.
Has an irascible disposition.

Post Reply