Inside: a benchmark of phpBB's performance under simulated load

[asperous]

Not 130 exactly, and I wasn't able to crash it with

Code: Select all

C:\Users\a5c\Desktop\ab\Apps\xampp\apache\bin>ab.exe -c 300 -n 10000 http://localhost/phpbb3/phpBB/viewforum.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
apr_socket_recv: An existing connection was forcibly closed by the remote host.   (730054)
Total of 819 requests completed

Though as you can see it does drop requests around that point. Yet when I tune my benchmark to jump right into somewhere way above ~500 concurrent clients (so probably around 130-200 requests per second) it crashes right away. Last message on error.log:

Code: Select all

[Sat Apr 27 18:02:42 2013] [warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting
zend_mm_heap corrupted
[Sat Apr 27 18:03:15 2013] [notice] Parent: child process exited with status 1 -- Restarting.
[Sat Apr 27 18:03:17 2013] [notice] Digest: generating secret for digest authentication ...
[Sat Apr 27 18:03:17 2013] [notice] Digest: done
[Sat Apr 27 18:03:18 2013] [notice] Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations

[asperous]

I think I'm starting to get the hang of this. I made some changes to my benchmark to get more samples. I upgraded apache and php to Apache/2.4.3 & PHP/5.4.7 to prevent those crashes I was getting before.

Samples taken green: phpBB 3.1 blue: phpBB 3.0

total_pages.png

(51.5 KiB) Downloaded 2759 times

Dropped requests green phpBB 3.1 blue: phpBB 3.0 (Look above at the chart--more samples means more dropped requests)

drop_pages.png

(48.55 KiB) Downloaded 2759 times

Latency Delays Grey: phpBB 3.1 Blue: phpBB 3.0

diff.png

(99.54 KiB) Downloaded 2759 times

Benchmark Grey: phpBB 3.1 Blue: phpBB 3.0

30_vs_31.png

(96.61 KiB) Downloaded 2759 times

Bonus! What happens if I change the session table to "MEMORY" (this question is why I made this benchmark) Grey: phpBB 3.1 innodb Blue: phpBB 3.1 memory

31mem_31nomem.png

(82.62 KiB) Downloaded 2759 times

[naderman]

It would also be interesting to be able to compare memory use of 3.0 vs. 3.1 rather than just speed.

This would end up being a rather useful tool if it would allow us to benchmark particular parts of phpBB before and after a pull request to identify potential problems, as well as identifying parts of phpBB that got slower in 3.1 to improve this prior to the release.

[Dog Cow]

Very interesting. What would be more useful would be some timers around the phpBB code so we can see which sections or queries are taking the longest to complete.

[Paul]

Very interesting. What would be more useful would be some timers around the phpBB code so we can see which sections or queries are taking the longest to complete.

Iam pretty sure with debug enabled that all queries are already timed.

[Dog Cow]

Very interesting. What would be more useful would be some timers around the phpBB code so we can see which sections or queries are taking the longest to complete.

Iam pretty sure with debug enabled that all queries are already timed.

But we already discussed earlier in this topic that the phpBB debug code is too much overhead.

[asperous]

Very interesting. What would be more useful would be some timers around the phpBB code so we can see which sections or queries are taking the longest to complete.

This wouldn't be too difficult. My system simply parses the actual response so we'd just need to throw these lines around:

Code: Select all

if (defined('PROFILING')) {
  $mtime = explode(' ', microtime());
  $section = "header";
  echo sprintf('%s > %.3f |', $section, $mtime[0] + $mtime[1] - $starttime);
}

$starttime is a global. With this format I can use > and | as delimiters and include the section name in my collection. I agree debug should be off since profiling should be as close to actual production as possible.

What sections do you suggest I profile?