My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 11079: Single threaded PAC resolution can kill performance of search
10 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  eroman@chromium.org
Closed:  Jul 2010
Cc:  darin@chromium.org, wtc@chromium.org, j...@chromium.org, mal.chromium@gmail.com, p...@chromium.org
M-6

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
 
Project Member Reported by eroman@chromium.org, Apr 27, 2009
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?
Apr 27, 2009
#1 eroman@chromium.org
(No comment was entered for this change.)
Summary: Single threaded PAC resolution can kill performance of search
Apr 27, 2009
#2 j...@chromium.org
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.
Cc: j...@chromium.org
May 6, 2009
#3 darin@chromium.org
I guess we could easily have a thread pool and use a V8 locker that we unlock during a 
DNS lookup.
May 6, 2009
#4 mal.chromium@gmail.com
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.
Status: Assigned
Owner: ero...@chromium.org
Labels: Mstone-2.1
May 21, 2009
#5 mal.chromium@gmail.com
(No comment was entered for this change.)
Cc: m...@chromium.org
Labels: -Pri-2 Pri-1
May 22, 2009
#6 lafo...@chromium.org
(No comment was entered for this change.)
Labels: -mstone-2.1 mstone-3
Jun 5, 2009
#7 j...@chromium.org
Eric, have you been working on this?  If not we should find someone who can work on it.
Labels: -mstone-3 Mstone-4
Jun 5, 2009
#8 eroman@chromium.org
> 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).
Jun 5, 2009
#9 eroman@chromium.org
(No comment was entered for this change.)
Labels: -Pri-1 Pri-2
Jul 27, 2009
#10 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Jul 27, 2009
#11 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Aug 5, 2009
#12 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Oct 16, 2009
#13 darin@chromium.org
Is this still on track for M4?
Oct 19, 2009
#14 eroman@chromium.org
> 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)

Oct 19, 2009
#15 eroman@chromium.org
(No comment was entered for this change.)
Blockedon: 24468
Oct 22, 2009
#16 j...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-4 Mstone-5
Dec 8, 2009
#17 darin@chromium.org
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.
Dec 9, 2009
#18 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Dec 17, 2009
#19 or...@chromium.org
Replacing labels:
   Area-BrowserBackend by Area-Internals

Labels: -Area-BrowserBackend Area-Internals
Mar 21, 2010
#20 darin@chromium.org
(No comment was entered for this change.)
Labels: Internals-Network
Mar 24, 2010
#21 eroman@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-5 Mstone-6
Apr 20, 2010
#22 p...@chromium.org
(No comment was entered for this change.)
Cc: p...@chromium.org
Jun 17, 2010
#23 eroman@chromium.org
bumping.
Labels: -Mstone-6 Mstone-7
Jun 30, 2010
#24 eroman@chromium.org
(No comment was entered for this change.)
Status: Started
Blockedon: -24468
Jul 1, 2010
#25 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Jul 8, 2010
#26 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Jul 8, 2010
#27 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Jul 8, 2010
#28 bugdroid1@gmail.com
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
------------------------------------------------------------------------

Jul 8, 2010
#29 eroman@chromium.org
Moving back to M6 as this should make it in time.
Labels: -Mstone-7 Mstone-6
Jul 12, 2010
#31 eroman@chromium.org
(No comment was entered for this change.)
Status: Fixed
Oct 12, 2012
#32 bugdro...@chromium.org
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.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#33 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-6 -Area-Internals -Internals-Network M-6 Cr-Internals Cr-Internals-Network
Mar 13, 2013
#34 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment

Powered by Google Project Hosting