performance degradation when using proxy.pac file with FF ESR 31
With Bug 923458 many people complained about a performance issue compared to other browsers when a proxy.pac file is used. The issue initially reported with the bug was resolved for ESR25 according to the statistics, but the general performance issue remained.
I had the same issue with ESR24 and ESR31.3 .
I was testing with www.bild.de. It took about 40 seconds to load the content completely. Without the proxy.pac file it took about 10 seconds.
I added a few alerts to the pac-File in order to get logs within the console for some analyses.
I found the following:
1. the pac.file is executed for every request, no matter if the host changed or not. With us the pac-File checks for IP-Adresses and host-names only. It is not necessary to execute the pac file for each and every request to the same remote host. So the question is, if we are able to disable this behaviour via about:config?
2. the content referenced by www.bild.de seems to be loaded sequentially and with a delay The overall time consumed by the proxy.pac file executions was about 4 Seconds compared to the 40 seconds of overall load time. So I checked the delay between executions of the pac-file and found an overall delay of 40 seconds. I expect that the delay between the calls to the pac-file is caused by the retrieval of contents from the remote host. So why are the requests executed sequentially?
Hint: Due to the times necessary for executing the pac-file and downloading the contents from the remote host, I would expect the logs generated by my alerts to be mixed (especially if myIpAddress took 1 Second). But the log is cleanly ordered by URL. (see attachment)
All Replies (4)
Unfortunately it looks like the attachment is not supported in the forum. You can use dnsResolve: resolves hostnames to an IP address. This function can be used to reduce the number of DNS lookups.
In about config there is only a limit to the number of persistent connections and change who makes the dns look ups: http://kb.mozillazine.org/Network.proxy.socks_remote_dns
So 1, I don't think so, but I could be wrong. 2. Are the timestamps of the sequential requests at different times? You can change who makes the request with the dns about:config and see if there is a difference in times.
Modified by guigs
Hi guigs2,
thanks for your response. As we only use myIpAddress once within our pac-File and only rely on dnsDomainIs(), ==-Comparisons and shExpMatch() and the sum of all pac-Executions was about 4 seconds compared to 40 seconds overall load time, I do not think that dns resolving is our issue.
I checked the seetings of the configuration you mentioned above. It is set to "false", so the client would try the resolve the dns names. Our admin told, that we do not use socks-Proxies, only http-Proxies.
Regarding sequential load of the contents included on www.bild.de from other web sites, I attached a screenthot.
Please note the red highlights. These show the start time in milliseconds of the pac-execution. I added this as a kind of id which represents a unique identifier together with the URL if the log items are mixed. But they are not, instead they are cleanly ordered by URL (for all 360 pac-file calls).
Moreover in the picture you can see the delay between the end of the last pac-file execution and the next one (blue timestamp in millisonds compared to the red timestamp of the next row saying "entered proxy.pac"). The delay sum up exactly to the 40 seconds the FF took to load the page completely.
Alone the fragment shown represents a delay of 630ms between the pac-file executions. If the contents would be loaded in parallel, there should be no such delay.
posting the image did not work with IE (out dated). So here it is
I found a workaround to avoid the delays by myIpAddress(). I extended our pac script with an own function that wraps myIpAddress(). My own function stores the result of myIpAddress() in a global variable I defined within our pac file. It also stores the time when this global variable was set.
The actual pac-Logic uses my own wrapper function instead of myIpAddress() directly. So my wrapper function returns the value of my global variable once it is set. To avoid problems due to changed network settings, my wrapper function checks if myIpAddress() was executed more than 10 seconds before and if so executes myIpAddress() again and stores the result in my global variable. This way we avoid too many calls to myIpAddress().
During my searches I found another bug item 1048468 which relates to myIpAddress(). I tested with FF35 which contains the bug fix - the performance issue was solved.
As we are using the ESR releases, the workaround using my wrapper-function is not necessary once the bug fix is included in the ESR release.