Guessing wildly, but while random other sorts of logs like reftests and builds work just fine, mochitest-other logs like http://tbpl.allizom.org/php/getParsedLog.php?id=5948685&full=1 are empty, like they're hitting a resource limit, or a surprisingly fatal PHP error or something. Minus the &full=1, http://tbpl.allizom.org/php/getParsedLog.php?id=5948685 works fine, but http://tbpl.allizom.org/php/getParsedLog.php?id=5948556 does not, since it was a green mochitest-other, so brief is full.

http://tbpl.swatinem.de/php/getParsedLog.php?id=5948685&full=1 and http://tbpl.swatinem.de/php/getParsedLog.php?id=5948556 both work, so maybe it is a memory limit problem. I have a limit of 256 on my server. I guess it can be bumped to 512M on production.

Unless the production server ignores our .htaccess php_value overrides, memory shouldn't be the problem... but php execution time might well be.

Empty arrays are falsy values, so logs without errors were effectively parsed three times.

This doesn't affect performance but makes it slightly clearer where time is spent when looking at profiles.

This is approximately what the profile looks like. It's not accurate because xdebug adds its own overhead, and because when I made this profile I had to comment out all preg_match lines except for two in GeneralErrorFilter::matchLine to get the execution to finish at all.

Maybe it would be a good idea to port the log parsing code to python and see what difference in performance it makes.

Comment on attachment 552850 [details] [diff] [review] part 3: break up FullLogGenerator::getLog into parts Review of attachment 552850 [details] [diff] [review]: ----------------------------------------------------------------- Much easier to read too, thanks.

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/d65010b7e413 http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/bbdea78e39b7 http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/5f08b66fdc3c

nthomas pulled those to allizom, and http://tbpl.allizom.org/php/getParsedLog.php?id=5976720&full=1 still seems a wee bit light on content.

nthomas, can you tempararily remove these lines from the .htaccess: php_value error_reporting 0 php_value display_errors 0 and paste the error that http://tbpl.allizom.org/php/getParsedLog.php?id=5976720&full=1 prints (if any) here? This isn't a good debugging situation. Maybe we should add parameters that turn on PHP error reporting again?

The server returns a 500, and the Apache error log has: [Mon Aug 15 16:29:45 2011] [error] [client 121.72.69.15] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 22507435 bytes) in /var/www/ tinderboxpushlog-staging/php/inc/FullLogGenerator.php on line 36 There are earlier entries in the staging log like that, so it's possible the .htaccess isn't being used. I'll take a look at the Apache config.

I've gotten so used to clicking in the blank space where our SVG close button isn't on the timeout alerts that I'd forgotten that I already knew .htaccess was being ignored on tbpl.allizom just like it is on tbpl.mozilla

The .htaccess files work on both tbpl.mozilla and tbpl.allizom now, and the log in comment #10 loads.

(In reply to Nick Thomas [:nthomas] from comment #13) > The .htaccess files work on both tbpl.mozilla and tbpl.allizom now Cool, I'll close bug 663593.

Deployed via bug 683241