923458 - [Regression v24 to v25] Slow loading of websites via proxy / pac file

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[MrX1980]

Attachment: IE8_Proxy_Settings.jpg

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Hello
there seems to be a regression between Firefox 24 (release) and 25 (beta).
The websites are loading extremly slow with Firefox 25 via proxy.
Both tested with clean profiles and "use system proxy settings" on Windows XP SP3.
I also tested it with Firefox Nightly 27.0a1 on different days/weeks and times.

IE8 Proxy Settings (see also the attached screenshot):
http://pac.t-systems.com:3132/proxy.pac
www-xx.dienste.telekom.de 8080


Actual results:

Loading some top websites of germany with Firefox 24 is ok, but Firefox 25 is extremly slow.


Expected results:

Firefox 25 should be as fast or faster than Firefox 24 and not much slower.

Comment 1

[MrX1980]

Example 1
http://www.bild.de/

Firefox 24 ~ 15 seconds to load the complete webssite
Firefox 25 ~ after 10 minutes there are still some missing contents and there is still page loading activity

Example 2
https://maps.google.de/

Firefox 24 ~ 10 seconds to load the complete webssite
Firefox 25 ~ 3 minutes to load the complete webssite


Is it possible to export the about:telemetry (Histograms) values ?
I think this could help you to find the problem.

---------------------------------------------------------------------------
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0
browser.startup.homepage_override.buildID	20130910160258

Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0
browser.startup.homepage_override.buildID	20131007213254

Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
browser.startup.homepage_override.buildID	20131010030202

Comment 2

[MrX1980]

Attachment: Telemetry_Firefox24.zip

Comment 3

[MrX1980]

Attachment: Telemetry_Firefox25.zip

Please look especially at the "HTTP_PAGE_..." values.

Comment 4

[MrX1980]

With buildID 20131022211721 it is still the same (tested with many websites).
Please look into it until v25 will be released. Many users could be afected.
Thanks

Comment 5

[MrX1980]

Intranet (internal) websites are working good, but not Internet (external) websites.

Comment 6

[Wayne Mery (:wsmwk)]

caused by bug 769764?

Comment 7

[kudrevatykh]

I have same issue after upgrading to v25, windows 7, x64, internet access configured via pac file.

Comment 8

[Andrea]

Same for me. Firefox 25 in Win7 behind proxy is unusable.

Comment 9

[arnaud.mercier]

Same issue with Win XP behind a proxy using a pac file.

Comment 10

[jh]

I am having the same issue.  It occurred immediately after I upgraded to 25 today.  I am using Windows 7 and using a proxy address.

Comment 11

[Andrea]

(In reply to Andrea from comment #8)
> Same for me. Firefox 25 in Win7 behind proxy is unusable.

Only when using a pac file.
If I set the proxy address manually, it works well.

Comment 12

[Laurent]

Same issue on Win7 64 bit behind a proxy using a pac file.

My pac file uses following functions:

myIpAddress
dnsDomainIs
isPlainHostName
shExpMatch

Comment 13

[Patrick McManus [:mcmanus]]

steve can you triage this. I can't think of any proxy related code that was new for 25 off the top of my head.

We're going to need someone's pac file who reproduces this. It pretty much cannot be reproduced without that information - so one of the reporters will need to help.

It can be sent to me privately if you like - [e-mail]

Comment 14

[Steve Workman [:sworkman] (INACTIVE)]

Looking into this now...

Comment 15

[Steve Workman [:sworkman] (INACTIVE)]

Sorry folks - I don't seem to be able to reproduce this on a Win 7 VM, so I'm no further forward.

I have a pac file donated by a commenter, using the same functions as Laurent in comment 12. I've tried using DIRECT and PROXY to see if there was a difference - none.

So, some questions:
-- do you have any plugins or add ons installed that might affect the connections?
-- do you have a proxy running locally?
-- what exactly are your proxy settings in Firefox?
-- anything else you can tell us about your local and network environment.

Comment 16

[Steve Workman [:sworkman] (INACTIVE)]

Also just tried upgrading from 24 to 25, but no slowdown noticed on 25.

Comment 17

[rgergre5g]

Attachment: anonymized pac file

I'm using the PortableApps version of Firefox on Win7 32Bit with "system proxy settings". Like #11 it works if setting the proxy manually. Attached an anonymized pac used in my company.

Comment 18

[Laurent]

Attachment: Network timings

Comment 19

[Laurent]

In Firefox integrated network console I can see that :

  - in case of manual proxy configuration, most of the requests are
    done in parallel

  - in case of automatic proxy configuration, most of the requests are
    done sequencially

  (see attachement - in french)

Comment 20

[Andrea]

I have the following impression.

The .pac file here is 410 lines of mostly shExpMatch.

The function myIpAddress() is called about 30 times.
If I remove the shExpMatch of the form

    shExpMatch(myIpAddress(), "some ip number")

(about 30 of them)

seems to be ok.

I am now running on a local proxy pac where these have been removed.

Am I just dreaming?

Comment 21

[jh]

I am using the PortableApps version for Firefox 25 on Win7 32-bit.  When I set the proxy manually there is no slowdown.  Slowdown persists with the company pac file.

Comment 22

[Steve Workman [:sworkman] (INACTIVE)]

Thanks everyone for the information. Unfortunately, I am still unable to reproduce this locally, but I see 3 possible leads to help diagnose the problem:

1 - PORTABLE APPS
Question: is anyone NOT using the PortableApps version of Firefox 25, i.e. anyone using a standard version of Firefox obtained directly from Mozilla? I see two comments referring to PortableApps, and the following forum page http://portableapps.com/node/38502 also mentions complaints about a slowdown in Firefox 25. One person on the forum writes that they see the degradation in a standard version of Firefox as well - I would like to confirm that, so please add a if you see this degradation on a standard, non-Portable Apps version.

(Note: I installed the PortableApps locally, but I do not see a slowdown).

2 - CONFIG FOR MAX CONNECTIONS
Can you please check some configuration values: please type about:config into the address bar, click to continue (because you're not going to change anything!) and then search for the following three preferences:
-- network.http.max-connections (256)
-- network.http.max-persistent-connections-per-proxy (32)
-- network.http.max-persistent-connections-per-server (6)
Note that the values in parentheses are the default values shipped with Firefox from Mozilla. Please add a comment here with the values in your configuration. Please remember to say if your installation is PortableApps or not.

FYI: These values relate to the amount of parallel connections Firefox can have per proxy and per server, which was mentioned in comment 19.

(Note: I am unable to see a change in the amount of parallelism between versions installed on my machine).

3 - FIREBUG
Someone in the forum also mentioned using the Firebug addon. This is also important: please check if you're running any addons/plugins/extensions by typing about:addons into the address bar.

All the information you can provide is very valuable in getting to the bottom of this.

Comment 23

[MrX1980]

1) normal installation (http://www.mozilla.org/en-US/firefox/all-beta.html -> german)
Firefox Setup 25.0b3.exe

2) clean/new profile without any addons or changing any default values.
I compared all network settings in about:config with Firefox 24 and they are identical.

I start Firefox with these parameters:
"C:\Program Files\Mozilla\Firefox\Release\firefox.exe" -no-remote -P "release"
"C:\Program Files\Mozilla\Firefox\Beta\firefox.exe" -no-remote -P "beta"
"C:\Program Files\Mozilla\Firefox\Aurora\firefox.exe" -no-remote -P "aurora"
"C:\Program Files\Mozilla\Firefox\Nightly\firefox.exe" -no-remote -P "nightly"

Comment 24

[MrX1980]

A hint/info from the forum:
http://forums.mozillazine.org/viewtopic.php?p=13171973#p13171973

Comment 25

[rgergre5g]

1) Can't install due to missing privileges
2) PortableApps has this default values
3) No addons, just a fresh and clean version. I also disabled all possible extensions like Java, Adobe, etc.

Comment 26

[kudrevatykh]

(In reply to Steve Workman [:sworkman] from comment #22)
> Thanks everyone for the information. Unfortunately, I am still unable to
> reproduce this locally, but I see 3 possible leads to help diagnose the
> problem:
> 
> 1 - PORTABLE APPS
> Question: is anyone NOT using the PortableApps version of Firefox 25, i.e.
> anyone using a standard version of Firefox obtained directly from Mozilla? I
> see two comments referring to PortableApps, and the following forum page
> http://portableapps.com/node/38502 also mentions complaints about a slowdown
> in Firefox 25. One person on the forum writes that they see the degradation
> in a standard version of Firefox as well - I would like to confirm that, so
> please add a if you see this degradation on a standard, non-Portable Apps
> version.
> 
> (Note: I installed the PortableApps locally, but I do not see a slowdown).

No portabble apps - normal installation

> 2 - CONFIG FOR MAX CONNECTIONS
> Can you please check some configuration values: please type about:config
> into the address bar, click to continue (because you're not going to change
> anything!) and then search for the following three preferences:
> -- network.http.max-connections (256)
> -- network.http.max-persistent-connections-per-proxy (32)
> -- network.http.max-persistent-connections-per-server (6)
> Note that the values in parentheses are the default values shipped with
> Firefox from Mozilla. Please add a comment here with the values in your
> configuration. Please remember to say if your installation is PortableApps
> or not.
> 
> FYI: These values relate to the amount of parallel connections Firefox can
> have per proxy and per server, which was mentioned in comment 19.
> 
> (Note: I am unable to see a change in the amount of parallelism between
> versions installed on my machine).

I have default values for that properties
 
> 3 - FIREBUG
> Someone in the forum also mentioned using the Firebug addon. This is also
> important: please check if you're running any addons/plugins/extensions by
> typing about:addons into the address bar.
> 
> All the information you can provide is very valuable in getting to the
> bottom of this.

I have slowdown without firebug and with clean profile.

More research:
There isn't  myIpAddress() in my pac file, but I have following code

    if (match(host,[".partner1.com$",
                    "^partner2.com$",
                    ".partner2.com$"])) {

        if (isResolvable(host)) {
            var server_ip;
            server_ip=dnsResolve(host);
            if (isIpFromNetwork(server_ip, '10.0.0.0/8')) {
                return internalProxies();
            }
            return internetProxies();
        }
        return internalProxies();
    }

and looks like slowdown starts when I try to download page that matches regexp and not resolvable by dns (I try to refresh one page and it downloaded very long time. All other pages, that downloaded normally before refresh, not downloaded until first, slow page, not finish download)

Comment 27

[Andrea]

Same here.
Standard Firefox v25, disabled all plugins, empty profile, default values in about:config.

Comment 28

[Steve Workman [:sworkman] (INACTIVE)]

This is great information everyone - really appreciate your continued feedback here.

I've been able to reproduce a slowdown as follows:

Firefox v25 (release) and v28 (Nightly) running in a Win7, 64 bit VM (VirtualBox).
Network access is restricted: the VM can only talk to the host machine (MacBook Pro running OSX 10.8).
Host machine has Squid proxy, and Apache - Apache serves the PAC file to the VM.

So, this means that the VM has no outside access apart from getting the PAC file, and subsequent HTTP access through the Squid proxy.

The PAC file is very simple:

function FindProxyForURL(url, host)
{
  var myAddress = myIpAddress();
  return "PROXY 192.168.56.1:8080";
}

(Note: I tested shExpMatch in there as well, but it made no difference).

I tested loading maps.google.de and maps.google.com. I saw a definite slowdown for resource loading using Fx 25 and 28. Fx 24 shows a little slowdown for the first load, but the rest of the page seems to load fast enough.

So we're making progress here.

I have some logs that I need to read over to find out where the slowdown is. I'll update the bug when I have more info.

Comment 29

[Steve Workman [:sworkman] (INACTIVE)]

Pat, I wondered if this was something to do with bug 882516 (removing the redundant DNS request), but that didn't land until Fx 26.

I'm wondering if the patch for Bug 887753 - "Server not found after reconnecting to etherpad" might have something to do with it ... more after some log reading.

Comment 30

[Jean J]

The bug occurs when the function "MyIpAddress" and a private DNS server are used.
When you call the "MyIpAddress" function, the client try to do also DNS resolution of the remote site (I don't know why, it's normally the proxy role...).
If your private DNS can't resolve internet address, for each get request, you have a bad dns response which slow down the connection.

Comment 31

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: v1.0 Use medium priority for DNS requests in ProxyAutoConfig::ResolveAddress

Pat, I think I found the problem. The patch in Bug 887753 blocks negative DNS cache entries being used for high priority requests, which ProxyAutoConfig::ResolveAddress used.

The patch I've uploaded changes the request to be MEDIUM. This should not affect hostname resolution of the proxy - negative cache entries will not be used for proxy resolution. But it will mean myIpAddress and dnsResolve functions in the PAC file will get negative cache entries if they exist. I don't think there's a conflict here with what Bug 997753 was trying to achieve - what do you think?

Thinking about priority, it does mean that requests for myIpAddress and dnsResolve will be lower priority than direct connections. However, these are synchronous functions, so spinning up multiple threads for parallel DNS resolution shouldn't be too much of an issue, right? And if PAC files are in use, then once the cache is primed, requests shouldn't even get to the getaddrinfo threads, except for refreshing the entries.

What do you think - would you rather have another flag added to nsIDNSService: "ALLOW_NEGATIVE_CACHE_ENTRIES"?

Comment 32

[Steve Workman [:sworkman] (INACTIVE)]

https://tbpl.mozilla.org/?tree=Try&rev=33b237822a5e

Comment 33

[Steve Workman [:sworkman] (INACTIVE)]

Folks, I'd like to make sure that the proposed fix works in your environments as well as my local test setup. Can you download and test the appropriate (non-debug) build for your platform from this link please?

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-33b237822a5e

At time of commenting, Windows is still building - please check back if it's still building when you read this.

Comment 34

[rgergre5g]

It works now for me. There is still a delay compared to Chrome or IE but at least it's seems to be usable again.
I replaced the files in a PortableApps installation with your build.

Comment 35

[kudrevatykh]

(In reply to Steve Workman [:sworkman] from comment #33)

It looks like works fine with clean profile, but still bit slowdown and freeze when using foxyproxy, but any case it better with your patch.

Thanks.

Comment 36

[MrX1980]

It is much better now and I can live with it.
Thanks

Comment 37

[Patrick McManus [:mcmanus]]

Comment on attachment 831118 [details] [diff] [review]
v1.0 Use medium priority for DNS requests in ProxyAutoConfig::ResolveAddress

Review of attachment 831118 [details] [diff] [review]:
-----------------------------------------------------------------

steve, you're on a roll lately!

Comment 38

[Patrick McManus [:mcmanus]]

this should be nominated for aurora and  beta

Comment 39

[Steve Workman [:sworkman] (INACTIVE)]

Thanks for testing and verifying folks! Glad to hear there's an improvement.

(In reply to rgergre5g from comment #34)
> It works now for me. There is still a delay compared to Chrome or IE but at
> least it's seems to be usable again.
> I replaced the files in a PortableApps installation with your build.

Just to be make sure you're fully aware, the build you're now using is bleeding edge code, based on Nightly Firefox, so there is a risk of some instability. As Pat suggested in commment 38, we will nominate this to be included in Aurora and Firefox Beta, both of which are further along the development pipeline and more stable. But if the Nightly build works for you and you're happy enough with the risk, by all means continue to use it.

Comment 40

[Steve Workman [:sworkman] (INACTIVE)]

(In reply to Patrick McManus [:mcmanus] from comment #37)
> Comment on attachment 831118 [details] [diff] [review]
> v1.0 Use medium priority for DNS requests in ProxyAutoConfig::ResolveAddress
> 
> Review of attachment 831118 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> steve, you're on a roll lately!

Thanks Pat! mozilla-inbound is closed this morning, so I'll check back later to land it. I'll nominate it for aurora and beta in a couple of days once it's landed baked a little on mozilla-central.

Comment 41

[L A Walsh]

FWIW, my housemate uses one of my computers and his FF is^h^hwas on autoupdate.

As soon as FF25 hit... no more internet and we are behind a squid proxy here.

Tried manual proxy settings (nada), use system settings (assume from IE?), load from URL
http://wpad/wpad.dat... (nada).

Finally, I just did a system restore to the day before -- he was put back in FF24
and he was back online.

Comment 42

[Andrea]

(In reply to Steve Workman [:sworkman] from comment #40)
> (In reply to Patrick McManus [:mcmanus] from comment #37)
> > Comment on attachment 831118 [details] [diff] [review]
> > v1.0 Use medium priority for DNS requests in ProxyAutoConfig::ResolveAddress
> > 
> > Review of attachment 831118 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > steve, you're on a roll lately!
> 
> Thanks Pat! mozilla-inbound is closed this morning, so I'll check back later
> to land it. I'll nominate it for aurora and beta in a couple of days once
> it's landed baked a little on mozilla-central.

Will this appear as an update of FF25 (like 25.0.1)?

I feel a lot of people will run away as it does not work.

Comment 43

[Lukas Blakk [:lsblakk] use ?needinfo]

Ship has already sailed for FF25.0.1 and so this will not make it in there, but tracking for FF26 and beyond so we get uplift for this regression if low risk.  Please nominate once it's landed & tested/verified on Nightly.

Comment 44

[Steve Workman [:sworkman] (INACTIVE)]

Apologies for the delay in landing this. For those that don't know, mozilla-inbound was closed for a few days. Landed now:

https://hg.mozilla.org/integration/mozilla-inbound/rev/1ac4f1a35bd8

I'll nominate for aurora and beta in a couple of days, once this has baked a little on Nightly.

Comment 45

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/1ac4f1a35bd8 along with bug 938803 for being one of the possible causes of breaking non-10.7 xpcshell tests like this: https://tbpl.mozilla.org/php/getParsedLog.php?id=30720160&tree=Mozilla-Inbound

Neither push build on OSX, so I don't know which was the cause.

Comment 46

[Steve Workman [:sworkman] (INACTIVE)]

After some analysis and testing, I'm pretty sure the failure was to do with Bug 938803. I'll have a fix uploaded soon in that bug. Meanwhile, this one should be able to land ok:

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc9c2520a53e

Comment 47

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/cc9c2520a53e

Comment 49

[Steve Workman [:sworkman] (INACTIVE)]

Comment on attachment 831118 [details] [diff] [review]
v1.0 Use medium priority for DNS requests in ProxyAutoConfig::ResolveAddress

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
-- 887753

User impact if declined:
-- Slowdown for Firefox users who connect to proxies via Proxy Auto Config (PAC).

Testing completed (on m-c, etc.):
-- Local testing passed.
-- Verified by users.
-- On m-c for a couple of days now.

Risk to taking this patch (and alternatives if risky):
-- No known risk to taking the patch.
-- No known alternative.

String or IDL/UUID changes made by this patch:
-- None.

Comment 50

[Steve Workman [:sworkman] (INACTIVE)]

Thanks Lukas!

https://hg.mozilla.org/releases/mozilla-aurora/rev/5b2e09991c01
https://hg.mozilla.org/releases/mozilla-beta/rev/5f839dbe0a09

Comment 51

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/5f839dbe0a09

Comment 54

[u279076]

MrX1980, can you please verify this is fixed in Firefox 26, 27 and 28?

Comment 55

[j.heinz]

Hi,

not yet fixed in Firefox 26.
It loads much faster when there is a manual proxy configuration.

But fixed in SeaMonkey 2.23

Comment 56

[Manfred Leber]

Hi anthony,
i just made some performance tests within  Deutsche Telekom intranet,
here are my results from the "German jury":

time (s) for losding www.welt.de:

Firefox 25.0.1:     195 sec.  ( the bug )
Firefox 24.2-ESR:    58 sec.  ( was never affected) 
Firefox 26.0:        58 sec.  ( fixed !)
Firefox 23.0:        40 sec.  
Internet Explorer 8: 25 sec. 
Google Chrome 31:    12 sec.

For me the bug is fixed, 
but Firefox is still slow compared to the other browsers.

Comment 57

[j.heinz]

Hi,

my tests with www.welt.de until finishing of the loading of all elements

Firefox 26.0 with automatic proxy configuration URL : 65 sec.
Firefox 26.0 with manual proxy configuration : 8 sec. (!)

For me, the bug is in Firefox 26.0 not fixed.

Comment 58

[j.heinz]

Hi,

now my tests with SeaMonkey 2.23:

and the same site (www.welt.de) until finishing of loading of all elements:

SeaMonkey 2.23 with automatic proxy configuration URL : 65 sec.
SeaMonkey 2.23 with manual proxy configuration : 8 sec. (!)

I see exactly the same behavior as in Firefox 26.0 - so it is not solved.

So I have to correct my comment from 2013-12-20 00:22:10 PST such,
that in SeMonkey 2.23 it is still not yet solved.

best regards

Comment 59

[j.heinz]

Hi,

now my tests with SeaMonkey 2.25a1:

and the same site (www.welt.de) until finishing of loading of all elements:

SeaMonkey 2.25a1 with automatic proxy configuration URL : 65 sec.
SeaMonkey 2.25a1 with manual proxy configuration : 8 sec. (!)

I see exactly the same behavior as in Firefox 26.0 and Seamonkey 2.23 - so it is not solved.

best regards

Comment 60

[Rob Janssen]

Did you test only the browsing or also the mail?
The reason I reported this bug (my bug 903451 was duped to this one) is that in Seamonkey the startup
suddenly was slow when a number of IMAP mail accounts was configured, and automatic proxy config
was present.   It takes 3 extra seconds of startup time per configured IMAP account.
Of course you cannot test this in Firefox, but how about Seamonkey?
I observed this problem first in Seamonkey 2.15 and it continues until 2.22.1.  I did test
2.25a1 build later and it appeared to solve that problem.  I had to go back to 2.20 because of
another bug, but I am still interested if a fix for this is forthcoming, and if those problems
really are the same (probably my bug was incorrectly duped, happens more often).

Comment 61

[u279076]

Steve, can you have a look over comment 55 and onward? 

In the case of comment 56 the goal of this bug was to resolve the regression we shipped in Firefox 25. I believe that has been resolved and any work to achieve parity with our competitors should be done in another bug report.

However, other comments suggest this is not fixed at all under certain configurations. Could you please follow-up here and decide whether we need to reopen this bug report or address those issues in a follow-up bug report?

Comment 62

[Steve Workman [:sworkman] (INACTIVE)]

Anthony, I will definitely look into this further. However, it's going to be the New Year before I get a good amount of time to really look into it. I'm going to leave needinfo?me as a reminder.

Comment 63

[MrX1980]

My results from today:

Firefox 26.0 release (new profile)
Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0
browser.startup.homepage_override.buildID = 20131205075310

http://web.de/ ~25sec
http://www.welt.de/ ~130sec
http://www.bild.de/ ~45sec
http://www.spiegel.de/ ~30sec
http://www.flickr.com/ ~10sec
https://maps.google.de/ ~15sec


Internet Explorer 8 (empty cache)

http://web.de/ ~10sec
http://www.welt.de/ ~15sec
http://www.bild.de/ ~10sec
http://www.spiegel.de/ ~15sec
http://www.flickr.com/ ~3sec
https://maps.google.de/ ~5sec

Merry Christmas and a happy new year!

Comment 64

[u279076]

(In reply to MrX1980 from comment #63)

Thanks for these results. Could you please repeat the test comparing Firefox 26, 27, and 28 to Firefox 24 on all of these sites?

Comment 65

[Manfred Leber]

(In reply to Manfred Leber from comment #56)

For your information, I am confirming my results from #56:

(all German locale, portable edition, 
 with proxy.pac file auto-configuration within the Deutsche Telekom Intranet)

[page load time in seconds]

http://www.welt.de          http://www.bild.de
19.0.2:       40                        25
23.0:         40                        25
24.0:         40                        25
25.0.1:      180                       180
26.0:         55                        34
27b4:         60                        35
-----------------
Chrome 31     15                        10

Best regards 
Manfred

Comment 66

[u279076]

(In reply to Manfred Leber from comment #65)
> For your information, I am confirming my results from #56

Thanks Manfred, would you mind also checking this with Firefox 28 (http://aurora.mozilla.org)?

Comment 67

[Manfred Leber]

in addition to #65
my results of http://www.welt.de 
including version 28:

load time via proxy pac:

Firefox Release  26.0 (de) : 50 sec.
Firefox Beta     27b4 (de) : 57 sec.
Aurora Firefox 28.0A2 (de) : 57 sec.


best regards
manfred

Comment 68

[u279076]

Thanks for your help Manfred.

Comment 69

[mikael.andres]

To me this bug isn't fixed at all.

Using a PAC file, Firefox 29 still does a DNS request and - depending on your OS and configuration - a NetBIOS request for each object it loads, which can lead to a huge slowdown of the overall operation, especially when your configured DNS servers are not able to resolve internet names (as it is often the case in organizations where you connect to the internet through a proxy).

I think that the right way to track this bug is not to measure the loading time of a page, but rather to perform a packet capture and look for inappropriate DNS requests. The only DNS requests the browser should be performing are to resolve the proxy(ies) address(es), that's all. To my knowledge it should NEVER perform a DNS request for the OCS hostname of the objects it has to load as long as the PAC file doesn't provide a DIRECT directive for the specific host.

Am I the only one still experiencing this bug??
Thanks

Comment 70

[j.heinz]

To me this bug still isn't fixed in firefox 29 at all too.

What is strange is that this bug was introduced last year but still there is no reason discovered for the problems.
Probable the reason is the behavior explaned by [e-mail]

The same problem still exists in seamonkey 2.25

Regards

Comment 71

[u279076]

Please file a new bug report if you are still experiencing issues. If you do file a new bug report please provide detailed steps to reproduce so we can try to replicate your issue. Thanks.

Comment 72

[DoVosch]

(In reply to Manfred Leber from comment #65)
> (In reply to Manfred Leber from comment #56)
> 
> For your information, I am confirming my results from #56:
> 
> (all German locale, portable edition, 
>  with proxy.pac file auto-configuration within the Deutsche Telekom Intranet)
> 
> [page load time in seconds]
> 
> http://www.welt.de          http://www.bild.de
> 19.0.2:       40                        25
> 23.0:         40                        25
> 24.0:         40                        25
> 25.0.1:      180                       180
> 26.0:         55                        34
> 27b4:         60                        35
> -----------------
> Chrome 31     15                        10
> 
> Best regards 
> Manfred

Manfred,

what tools were used to calculate the load time? (Chrome and Firefox) 

I am facing this same situation and want to perform the tests. 

thank you

Comment 73

[Patrick McManus [:mcmanus]]

the actual contents of the pac file is what is going to be interesting here..

Comment 74

[DoVosch]

Attachment: anonymized pac file

Comment 75

[Manfred Leber]

(In reply to DoVosch from comment #72)

Just a stopwatch,
from the start to the end of loading (complete page of www.welt.de)
 
FF 29.0.1  = 50 sec.

(Chrome 34 = 15 sec.)

We have several thousand firefox users, 
no complains about the load time of firefox.


best regards 
Manfred




> (In reply to Manfred Leber from comment #65)
> (In reply to Manfred Leber
> from comment #56)
> 
> For your information, I am confirming my results from
> #56:
> 
> (all German locale, portable edition, 
>  with proxy.pac file
> auto-configuration within the Deutsche Telekom Intranet)
> 
> [page load
> time in seconds]
> 
> http://www.welt.de          http://www.bild.de
>
> 19.0.2:       40                        25
> 23.0:         40               
> 25
> 24.0:         40                        25
> 25.0.1:      180          
> 180
> 26.0:         55                        34
> 27b4:         60         
> 35
> -----------------
> Chrome 31     15                        10
> 
>
> Best regards 
> Manfred

Manfred,

what tools were used to calculate the
> load time? (Chrome and Firefox) 

I am facing this same situation and want
> to perform the tests. 

thank you

Comment 76

[MrX1980]

Info:
Firefox Nightly 35.0a1 (buildID: 20140929030205) is now much faster then Firefox 32.0.3
Firefox 33 & 34 not yet tested.

Comment 77

[jan]

Hello,

we have the same performance issue with FF SR 24. 
There are two different points in my opinion. 

First of all, the performance issue Manfred raised with this bug for ESR25. This seems to be resolved according to the statistics.

The second issue the most other guys complain about is the slowliness compared to other browsers when the proxy.pac file is used.

I tested (added alerts to the proxy.pac including time stamps and urls called) and found the following:

1. proxy.pac runtime itself is not an issue with us (took about 200ms for loading www.bild.de over all)
-> the calls to myIPAddress are not the problem as we expected initially

2. proxy.pac is executed about 90 times when calling www.bild.de; repeatedly for the same hosts
-> Issue 1: why is the pac-file executed for the same host names again and again?

3. performance degradation when the proxy.pac is loaded from a remote host
   (with our pac-file loaded from a remote host, loading of www.bild.de took 40s, compared to 11s when I   I used the same pac-file stored on my local hard drive)
-> Issue 2: why does the usage of a remote file compared to a local file have such an impact (I would expect that the file is loaded once)?

Comment 78

[Rob Janssen]

"proxy.pac is executed about 90 times when calling www.bild.de; repeatedly for the same hosts
-> Issue 1: why is the pac-file executed for the same host names again and again?"

Because the pac file can vary its decision not only based on the hostname but also on other parts
of the URL.   For example, it can decide to send content that looks like being dynamic directly
to the host, and content that looks like static via a proxy.

Internet explorer has a setting to select between "optimized" (incorrect) handling of the pac
file by caching the first result for each host, and normal (correct) handling.

Comment 79

[jan]

ok, understand issue 1. 
Is there maybe a setting within the firefox similar to the IE for "incorrect" handling to execute the pac-file once per host-name?

Comment 80

[u279076]

(In reply to jan from comment #77)
> Hello,
> 
> we have the same performance issue with FF SR 24. 
> There are two different points in my opinion. 

Hi Jan,

Can you please report your issue to support.mozilla.org? Seeking support on a closed bug report is ineffective and strongly discouraged. If our Support people think you're experiencing a Firefox bug, a new bug report should be filed.

As an aside, Firefox ESR 24 was end-of-life some months ago. You should update to the ESR 32 branch and see if the issue remains. But again, support.mozilla.org is the right place to continue this conversation.

Thank you