Closed Bug 830920 Opened 12 years ago Closed 12 years ago

Reduce running time of test_websocket_basic.html


(Core :: Networking: WebSockets, defect)

Not set



Tracking Status
firefox19 --- fixed
firefox20 --- fixed
firefox21 --- fixed
b2g18 --- fixed


(Reporter: jduell.mcbugs, Assigned: jduell.mcbugs)



(Whiteboard: [qa-])


(1 file)


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.

Attachment #702451 - Flags: review?(bugs) → review+
Blocks: 829512

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.
Attachment #702451 - Flags: approval-mozilla-beta?
Attachment #702451 - Flags: approval-mozilla-b2g18?
Attachment #702451 - Flags: approval-mozilla-aurora?
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).

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:
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.
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
(Also, this is in my queue to land on Aurora once it reopens)
Blocks: 833414
Marking this [qa-]. Please remove the tag if there is anything the QA can help with.
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.