5

At phpMyAdmin we suffer strange testsuite slowdown for some time. We've been able to trace the problems down to situation when xdebug is enabled (for code coverage) and there is an error inside ob_start/ob_end_clean block. Removing either of these does drastically reduce testsuite time.

                xdebug       enabled      disabled
ob_start failure tests
enabled                       20 min        15 s
disabled                      1 min         15 s

This is just to show how huge the difference is and why we would like to get rid of that.

At smaller scale, this can be shown with single test test/classes/PMA_Advisor_test.php:

                xdebug       enabled      disabled
ob_start failure tests
enabled                       7.2 s         0.1 s
disabled                      2.6 s         0.1 s

Here the difference is removing of single dataset for one test (in case you would be looking into the sources, it's the last data set) and causes test to take less than half of the time! UPDATE: At this particular case the problem can be mitigated using xdebug.default_enable=0, but that does not change much for whole testsuite.

At first glance it indeed looks like some bug in xdebug, but we have been unable to produce smaller testcase than above, what sounds suspicious. Any ideas how to debug the issue further of how to figure out what is actually causing this slow down?

Michal Čihař
  • 9,799
  • 6
  • 49
  • 87
  • Why do you think this is too slow? What does xdebug report on the error? Perhaps it's simply logging a lot more information than without the error. – Martijn Jul 16 '12 at 11:34
  • Because it did not use to be that slow :-). As the only thing testsuite is using from xdebug is coverage analysis, I'd not expect it to slow down on error. – Michal Čihař Jul 16 '12 at 11:41
  • Actually `xdebug.default_enable=0` removes the difference for the single test case, so stacktrace collection is indeed one of cuplrits, thanks for the hint! Unfortunately it does not do the trick for full testsuite, so there must be some other issue as well. – Michal Čihař Jul 16 '12 at 12:03
  • Also there is one more indication that something fishy is going on in this case - the phpunit's output is gone after error inside ob_start/ob_end_clean block. – Michal Čihař Jul 16 '12 at 12:30
  • Is the bulk of the 20 minutes spread evenly over multiple testcases or all wasted on a single one? – Martijn Jul 16 '12 at 13:47
  • Actually it looks like it is spent around tests, at least numbers phpunit reports say so (it says it spent 30 seconds in running the tests). – Michal Čihař Jul 16 '12 at 13:54
  • Did you ever get to the bottom of this Michal? – Alan Hollis Aug 09 '13 at 14:50
  • Simply the coverage processing is too slow. The only way we found around is disabling coverage for continuous testing and do it only daily. – Michal Čihař Aug 11 '13 at 09:40

2 Answers2

1

I've had this problem due to the profiler being on, which will also be generating huge cachegrind files.

Check that xdebug.profiler_enable = 0

> documentation

scipilot
  • 6,681
  • 1
  • 46
  • 65
0

My tests ware slow because I enabled show_local_vars for some reason which I can't remember now. http://xdebug.org/docs/all_settings Hope this info will be helpful.

Aram
  • 696
  • 4
  • 16