[Webkit-unassigned] [Bug 88134] 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





--- Comment #4 from Ami Fischman <fischman at chromium.org>  2012-06-01 14:26:21 PST ---
(In reply to comment #3)
> > (In reply to comment #0)
> > > 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.
> > 
> > If we're including the time to start apache in the test's timeout budget that's also just a bug we should fix.
> 
> At a quick glance at the code, we wait and check that the http server is correctly started up and responding to requests before we try to run any http tests, so I doubt this is what's going on.
> 
> Unless our logic for testing whether the server is up and running is wrong. See _is_server_running_on_all_ports in Tools/Scripts/webkitpy/layout_tests/servers/http_server_base.py to see that code. It seems to me that connecting to the server via a socket should be a sufficient test, but maybe it's not.

The httpd.conf only requests a single httpd process to be started initially.
Apache uses a whole process ("Server" in httpd.conf-speak) to serve a request, and the only parallelism it supports is multi-process (one process per request).
So the existing conf requests a single process to start up, and the controller declares it started up when it can connect to the socket, which is all well and good, but as soon as the other 15 DRTs pile on their own requests, apache has to spin up 15 more httpd processes.  It's this spin-up that is currently (incorrectly) counted against the test's timeout budget.

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