Created attachment 702451 [details] [diff] [review] reduce test count iteration from 100 -> 10. smaug: Apparently test_websocket_basic (which sends 100 WS msgs, and calls forcegc() after each one) is now taking so long to run (300 sec) that it gets timed out. I'm not sure of why this takes longer than it used to (apparently billm says they added more debug assertions in the GC--the timeout happens only for debug builds), nor why we felt the need to make the loop run 100x, which seems like a lot. This path just drops it down to 10x. Does that sound ok? This is blocking 818023.
Attachment #702451 - Flags: review?(bugs)
Comment on attachment 702451 [details] [diff] [review] reduce test count iteration from 100 -> 10. Ok
Attachment #702451 - Flags: review?(bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/2c96e14d0557 Landed with DONTBUILD after asking edmorley, since there's no real reason to burn a whole bot run on this trivial change. Let me know if this needs to land on aurora/beta.
Comment on attachment 702451 [details] [diff] [review] reduce test count iteration from 100 -> 10. Apparently this test is not quite hitting mochitest timeout (300 seconds) on aurora/beta, but this does seem like low-hanging fruit for reducing test server load. [Approval Request Comment] User impact if declined: bot cycles burned Risk to taking this patch (and alternatives if risky): none, test-change only.
FYI, I collected all the timestamps from the recent logs of tbpl, and I noticed that beta is still at 180s, and latest revisions of inbound are above 300s (not higher due to timeouts). http://people.mozilla.com/~npierron/find-websocket-regression/ Can someone find precisely what might be the sources of these slow down ? Each file contains numbers which are directly coming from tbpl's ftp logs: ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32-debug/
The slowdown is most likely a change in GC, so hopefully Ollie knows or can CC people who do. The behavior here (send a single message over and over and forceGC each time) is not realistic behavior, but I'd really love to be assured that we know why the timing is going up and that it's OK.
I don't know about changes to GC. (I hack CC only)
Comment on attachment 702451 [details] [diff] [review] reduce test count iteration from 100 -> 10. test-only, approving for branches
Attachment #702451 - Flags: approval-mozilla-beta?
Attachment #702451 - Flags: approval-mozilla-beta+
Attachment #702451 - Flags: approval-mozilla-b2g18?
Attachment #702451 - Flags: approval-mozilla-b2g18+
Attachment #702451 - Flags: approval-mozilla-aurora?
Attachment #702451 - Flags: approval-mozilla-aurora+
billm added a bunch of checking to debug GCs, so they are a lot slower now. It doesn't matter much in general, but if you are running it 100 times it could add up.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
status-b2g18: --- → fixed
status-firefox19: --- → affected
status-firefox20: --- → affected
status-firefox21: --- → fixed
status-firefox19: affected → fixed
(Also, this is in my queue to land on Aurora once it reopens)
status-firefox20: affected → fixed
Marking this [qa-]. Please remove the tag if there is anything the QA can help with.
You need to log in before you can comment on or make changes to this bug.