[Webkit-unassigned] [Bug 88134] New: new-run-webkit-tests should spin-up enough httpd processes to avoid timeouts

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=88134

           Summary: new-run-webkit-tests should spin-up enough httpd
                    processes to avoid timeouts
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: fischman at chromium.org
                CC: abarth at webkit.org, ojan at chromium.org


I noticed recently that on my z600/chromium/linux/16-core setup if I run a test (e.g. http/tests/media/video-buffered.html) with --iterations=100 (or 1000), the first 1-3 runs pass, then the next 13-15 runs timeout, and then the rest pass.  If I bump the {{Min,Max}Spare},Start}Servers to 16 in http://trac.webkit.org/browser/trunk/LayoutTests/http/conf/apache2-debian-httpd.conf then I get a 100% pass rate.  My guess is that spinning up the new apache processes is eating too much of the test's timeout budget, but once they're spun up the test does fine.

Is there a reason not to always run with extra processes?  (what's the minimum machine footprint n-r-w-t is expected to work on?)
IWBN if n-r-w-t could configure its httpd to run as many apache processes as DRT processes, but absent that kind of setup, would bumping the counts to 32 (or something else likely to be >= #cores on dev machines) be acceptable?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.