Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 11079 Single threaded PAC resolution can kill performance of search
Starred by 10 users Project Member Reported by eroman@chromium.org, Apr 27 2009 Back to list
Status: Fixed
Owner: eroman@chromium.org
Closed: Jul 2010
Cc: mal.chro...@gmail.com, pam@chromium.org, wtc@chromium.org, darin@chromium.org, jar@chromium.org
Components:
OS: All
Pri: 2
Type: Bug
M-6

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
I debugged a slowness from a user's log where the combination of background requests + singled-
threaded PAC resolving + and slow DNS resolving for non-existent hosts became pretty bad.

====================
Here is the symptom:
====================

User types "test2" into omnibox and hits enter. On occasion it takes 16+ seconds to load the 
google search results.

====================
Here is what happened:
====================

1. User types "test2" into the omnibox and hits enter.

2. Omnibox starts a background request [A] <http://test2/>. This is the request that will be used 
to populate a "Did you mean http://test2/" infobar if it succeeds.

==> While this request [A] is intended to be a background query, I will show how it actually ends 
up blocking the load of the intended google search results. <===

3. Omnibox starts a request for [B] <http://www.google.com?q=test2>. This is the load that the 
user actually cares about.

4. We start to resolve the proxy for [A] <http://test2/"> . Since the user has a custom PAC 
script, we kick it over to the solo proxy resolver thread to run in V8:

// User's PAC script:

function FindProxyForURL(url, host) {
  if (isInNet(host, "10.63.0.0", "255.255.0.0"))
    return "PROXY 129.184.137.55:80";

  ...
  <Four more "isInNet(host, XXX, YYY)" tests here>
  ..

  return "DIRECT";
}

In particular, the javascript calls to isInNet(host, ...) will do blocking DNS resolves, since the 
specified |host|, "test2", is not an IP address. Unfortunatley dnsResolve("test2") is going to 
take 16 seconds to complete (with a failure), as there is no host "test2" on this user's network 
(nor was that their intent anyway).

Meanwhile, the request [B] <http://www.google.com?q=test2> will be blocked waiting on its proxy 
resolve step. Not because it takes a long time to run FindProxyForURL("http://www.google.com?
q=test"), but because the previous FindProxyForURL("http://test2/") is holding up the V8 thread 
until the DNS resolve completes.

====================
Solutions:
====================

Obviously the bottleneck here is that there is only a single thread running the PAC scripts. So if 
one proxy resolve takes a long time (probably because it is doing DNS resolves), we are hosed.

The obvious solution is to have a pool of threads running the v8 proxy resolvers, each with with 
its own copy of the script's context.

The cons are going to be more memory usage, more complexity, and possibly break compatibility on 
some scripts (i.e. for scripts stupid enough to rely on global state between runs; probably not 
that many)


Is this a problem we want to address?
 
Comment 1 by eroman@chromium.org, Apr 27 2009
Summary: Single threaded PAC resolution can kill performance of search (was: NULL)
Comment 2 by jar@chromium.org, Apr 27 2009
I think we're in a unique position to be able to fix this.  I'm sad that PAC scripts 
can be written poorly... but it would be cool if we worked around their 
implementation to the extent possible.  I think the motto should be "Chrome just 
works," and this is a good example ;-)

Domain not founds often (only) causes an 11 second delay <sigh>, and the average Iv'e 
seen from UMA is around 5 seconds.  I guess that even if we did expedite the follow 
on activities, the user would tend to see that terrible delay.  On the off chance 
that the PAC script did more that one such time-consuming lookups, it would be VERY 
nice to be able to overlap them (not to mention the google.com resolution).

For example: If the user asked to see:
test2
I can imagine a PAC script trying to resolve:
test2
then trying
test2.theirdomain.com
etc.
It would be way cool if we could detect a "long pending resolution" and re-run the 
script a second time in another JS interpreter, and have it *assume* that the 
resolution of "test2" will indeed return "name not found."  That would give the 
second interpreter a chance to try a second lookup for "test2.theirdomain.com", etc.  
If we later found out that the first lookup *did* indeed come back with a "not found" resolution, that would be justification IMO for using the results of the second run, 
which is already quite far along.

It is true that PAC scripts can be non-deterministic, and even time varying, but I'd 
like to argue that IF we can show one run of the script that returns a value 
(somehow, with all external questions answered), then we should be allowed to go with 
that value.
Comment 3 by darin@chromium.org, May 6 2009
I guess we could easily have a thread pool and use a V8 locker that we unlock during a 
DNS lookup.
Labels: Mstone-2.1
Status: Assigned
According to Darin, we had the same problem in 1.0 (one WinHTTP PAC query at a time), 
so this isn't something I'll block 2.0 on. It's something we should work on solving 
soon, though.
Labels: -Pri-2 Pri-1
Labels: -mstone-2.1 mstone-3
Comment 7 by jon@chromium.org, Jun 5 2009
Labels: -mstone-3 Mstone-4
Eric, have you been working on this?  If not we should find someone who can work on it.
> Eric, have you been working on this?  If not we should find someone who can work on it.

No I haven't.

I got busy with the DNS cache stuff which I feel is more important for performance than this bug (in fact I say this should be 
declassified from P1 status).

When trying to design a solution here, I got blocked by <http://crbug.com/11746> -- I didn't want to introduce abstractions that 
would then need to be rewritten for an OOP transition. But that makes the task considerably harder. I think the better course of 
action is to defer this to _after_ PAC has moved out of process (11746).
Labels: -Pri-1 Pri-2
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21631 

------------------------------------------------------------------------
r21631 | ericroman@google.com | 2009-07-26 14:12:20 -0700 (Sun, 26 Jul 2009) | 19 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/resolve_proxy_msg_helper_unittest.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver.h?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_mac.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_mac.h?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_perftest.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.h?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8_unittest.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_winhttp.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_winhttp.h?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=21631&r2=21630
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=21631&r2=21630
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver_unittest.cc

Remove the concept of threading from ProxyService, and move it into the ProxyResolver dependency.

ProxyResolver may now complete requests asynchronously, and is defined to handle multiple requests.

The code from ProxyService that queued requests onto the single PAC thread has moved into SingleThreadedProxyResolver. 

This refactor lays the groundwork for:

(1) http://crbug.com/11746 -- Run PAC proxy resolving out of process.
(Can inject an IPC bridge implementation of ProxyResolver)


(2) http://crbug.com/11079 -- Run PAC proxy resolving on multiple threads.
(Can implement a MultithreadedProxyResolver type class; still complications around v8 threadsafety though).

BUG=http://crbug.com/11746, http://crbug.com/11079
TEST=existing unit-tests.

Review URL: http://codereview.chromium.org/149525
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=21829 

------------------------------------------------------------------------
r21829 | ericroman@google.com | 2009-07-27 23:29:51 -0700 (Mon, 27 Jul 2009) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=21829&r2=21828

Clean-up proxy_service_unittest.cc, to remove dependency on SingleThreadedProxyResolver.

This was a TODO generated in <http://codereview.chromium.org/149525>

This simplifies the test code since everything is running on one thread.

BUG=http://crbug.com/11746, http://crbug.com/11079

Review URL: http://codereview.chromium.org/160155
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=22591 

------------------------------------------------------------------------
r22591 | eroman@chromium.org | 2009-08-05 22:42:11 -0700 (Wed, 05 Aug 2009) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/resolve_proxy_msg_helper_unittest.cc?r1=22591&r2=22590
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=22591&r2=22590
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_resolver.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=22591&r2=22590

Remove dependency on SingleThreadedProxyResolver from resolve_proxy_msg_helper_unittest.cc.

Extracts MockAsyncProxyResolver to "mock_proxy_resolver.h".

This should be the last unittest that needs cleanup post r21631.

BUG=http://crbug.com/11079

Review URL: http://codereview.chromium.org/160619
------------------------------------------------------------------------

Comment 13 by darin@chromium.org, Oct 16 2009
Is this still on track for M4?
> Is this still on track for M4?

Nope, I haven't had time to do work on these features.

I feel that this feature should depend on first having:
- out of process PAC
- having support for isolates in V8

Another big concern is how much memory this is going to cost us.

Right now, the V8 heap in browser for PAC is substantial -- Jim observed it as costing us 30MB.... So we 
would expect each additional thread to cost about another 30MB. (bug 24468)

Blockedon: 24468
Comment 16 by jon@chromium.org, Oct 22 2009
Labels: -Mstone-4 Mstone-5
I believe that isolates in V8 are not required for this.  In fact, it may be better to 
share a heap since that would use less memory.  When we start using threads for proxy 
resolution, we'd probably want to have just as many threads as we allow for DNS 
queries.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=34238 

------------------------------------------------------------------------
r34238 | eroman@chromium.org | 2009-12-09 23:23:40 -0800 (Wed, 09 Dec 2009) | 15 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_cache.cc?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_cache.h?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_cache_unittest.cc?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl_unittest.cc?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/hresolv/hresolv.cc?r1=34238&r2=34237
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request_view_net_internals_job.cc?r1=34238&r2=34237

Cache failed DNS resolutions for 1 second.

This is a very small time to live, since we want to be able to respond quickly when formerly unresolvable names become resolvable.

Even such a small time is still useful, since cache misses for unresolvable names can be extremely costly (order of several seconds).

For example, in our corp PAC script, the URL's host is resolved 3 times, so:
  Without caching, total runtime is (2.5 seconds) * 3 --> 7.5 seconds.
  Whereas with caching it would be: (2.5 seconds) * 1 --> 2.5 seconds

This time to live will need to be tuned as part of bug 25472.

BUG= 11079 

Review URL: http://codereview.chromium.org/464084
------------------------------------------------------------------------

Comment 19 by oritm@chromium.org, Dec 17 2009
Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

Comment 20 by darin@chromium.org, Mar 21 2010
Labels: Internals-Network
Labels: -Mstone-5 Mstone-6
Comment 22 by pam@chromium.org, Apr 20 2010
Labels: -Mstone-6 Mstone-7
bumping.
Blockedon: -24468
Status: Started
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51434 

------------------------------------------------------------------------
r51434 | eroman@chromium.org | 2010-07-01 15:20:50 -0700 (Thu, 01 Jul 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver_unittest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_resolver.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_mac.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_perftest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8_unittest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_winhttp.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_winhttp.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_unittest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver.h?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver_unittest.cc?r1=51434&r2=51433
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge_unittest.cc?r1=51434&r2=51433

Optimization: reduce the copying of string data between C++ and javascript in proxy_resolver_v8.cc. 

This is done by sharing the string storage using ExternalStringResource. 

An accompanying change was to pass around the PAC script data as a UTF16 string16 rather than a UTF8 std::string -- this required changing plumbing in the other files. 

This optimization will be important when creating multiple ProxyResolverV8's so they don't end up duplicating the script text. 

BUG= 11079 
Review URL: http://codereview.chromium.org/2817043
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51877 

------------------------------------------------------------------------
r51877 | eroman@chromium.org | 2010-07-08 12:21:10 -0700 (Thu, 08 Jul 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_log_event_type_list.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=51877&r2=51876
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/multi_threaded_proxy_resolver.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/multi_threaded_proxy_resolver.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/multi_threaded_proxy_resolver_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.cc?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.cc?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8_unittest.cc?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=51877&r2=51876
   D /trunk/src/net/proxy/single_threaded_proxy_resolver.cc
   D /trunk/src/net/proxy/single_threaded_proxy_resolver.h
   D /trunk/src/net/proxy/single_threaded_proxy_resolver_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge.cc?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge.h?r1=51877&r2=51876
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge_unittest.cc?r1=51877&r2=51876

Add the capability to run multiple proxy PAC scripts in parallel.

Refactors SingleThreadedProxyResolver into MultiThreadedProxyResolver.

New threads are created lazily on demand, up to a fixed maximum.

Note that this CL does NOT change the policy in Chrome -- it will continue to use a single thread for proxy resolving, but using the new code to do so.

BUG= 11079 
Review URL: http://codereview.chromium.org/2822043
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51893 

------------------------------------------------------------------------
r51893 | eroman@chromium.org | 2010-07-08 14:10:27 -0700 (Thu, 08 Jul 2010) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_log_event_type_list.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=51893&r2=51892
   D /trunk/src/net/proxy/multi_threaded_proxy_resolver.cc
   D /trunk/src/net/proxy/multi_threaded_proxy_resolver.h
   D /trunk/src/net/proxy/multi_threaded_proxy_resolver_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.cc?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.cc?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8_unittest.cc?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=51893&r2=51892
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/single_threaded_proxy_resolver_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge.cc?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge.h?r1=51893&r2=51892
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge_unittest.cc?r1=51893&r2=51892

Revert 51877, since SpdyNetworkTransactionTest.CorruptFrameSessionError started failing after this check-in (but only on vista modules builder).
BUG= 48588 

Original CL description:

Add the capability to run multiple proxy PAC scripts in parallel.

Refactors SingleThreadedProxyResolver into MultiThreadedProxyResolver.

New threads are created lazily on demand, up to a fixed maximum.

Note that this CL does NOT change the policy in Chrome -- it will continue to use a single thread for proxy resolving, but using the new code to do so.

BUG= 11079 
Review URL: http://codereview.chromium.org/2822043

TBR=eroman@chromium.org
Review URL: http://codereview.chromium.org/2945004
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51924 

------------------------------------------------------------------------
r51924 | eroman@chromium.org | 2010-07-08 20:32:00 -0700 (Thu, 08 Jul 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_log_event_type_list.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=51924&r2=51923
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/multi_threaded_proxy_resolver.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/multi_threaded_proxy_resolver.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/multi_threaded_proxy_resolver_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.cc?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.cc?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_v8_unittest.cc?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=51924&r2=51923
   D /trunk/src/net/proxy/single_threaded_proxy_resolver.cc
   D /trunk/src/net/proxy/single_threaded_proxy_resolver.h
   D /trunk/src/net/proxy/single_threaded_proxy_resolver_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge.cc?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge.h?r1=51924&r2=51923
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/sync_host_resolver_bridge_unittest.cc?r1=51924&r2=51923

Add the capability to run multiple proxy PAC scripts in parallel.

Refactors SingleThreadedProxyResolver into MultiThreadedProxyResolver.

New threads are created lazily on demand, up to a fixed maximum.

Note that this CL does NOT change the policy in Chrome -- it will continue to use a single thread for proxy resolving, but using the new code to do so.

BUG= 11079 
Review URL: http://codereview.chromium.org/2822043
------------------------------------------------------------------------

Labels: -Mstone-7 Mstone-6
Moving back to M6 as this should make it in time.
Status: Fixed
Project Member Comment 32 by bugdroid1@chromium.org, Oct 12 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 33 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Mstone-6 -Area-Internals -Internals-Network M-6 Cr-Internals Cr-Internals-Network
Project Member Comment 34 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment