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.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.
phpBB 3.1 load
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.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.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.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.
Re: phpBB 3.1 load
Re: phpBB 3.1 load
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.
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.
Re: phpBB 3.1 load
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)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.
Re: phpBB 3.1 load
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
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.
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.
Re: phpBB 3.1 load
This is one from xhprof: http://theexiled.pwnageservers.com/phpb ... lgraph.pngJoshyPHP 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.
Top level stats for index.php: http://theexiled.pwnageservers.com/phpbb_tests/xhprof/
That was run on Alpha2 with a warm cache.
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
Re: phpBB 3.1 load
Btw we also announce that the memory limit minimum is 16MB now, up from 8MB in 3.0
Member of the Development-Team — No Support via PM
Re: phpBB 3.1 load
That's nice, thanks. What version of PHP and which opcode cache was that?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.
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.
Re: phpBB 3.1 load
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?
First -> Peak Memory Usage: 9.5 MiB
Now -> Peak Memory Usage: 3.8 MiB
Will be so also in 3.1.4?
Re: phpBB 3.1 load
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.
Re: phpBB 3.1 load
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.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?
Has an irascible disposition.