The thing about wireshark is that it only shows your what's going on. Without fundamental knowledge of the underlying protocols, it's not useful.
Also, know that a blanket rule for noscript to disallow all will break many pages. I used to allow the things that seemed required to make certain page work, but it was arduous. Now, I allow all and blacklist the bad ones.
]]>Here is my advice for futher testing and observation for you to do:
Test with firefox with the noscript extension, which allows one to allow and disallow scripts per host or domain. The default settings will block all scripts. See how long the page load takes. I am guessing it will be a short, just as we saw with curl, which only downloads the page's HTML and nothing else.
If this is the case, and it's fast with scripts disabled, proceed to test by allowing one script domain one at a time and reloading until a slowness is apparent, and which point you can filter down the pcap to the specific host to observe and compare.
I did exactly what you suggested, enabled NoScript 2.5.7, in FireFox 16.0.1 and Drudgreport.com loaded too fast to measure.
So now it's clear to me that scripts are the nub of the problem.
A little research found this for google: NotScripts for Chrome.
After downloading and installing it the web page now loads seemingly instantly. I'm going to install it in all Linux and Windows OS's.
So thank you for your patience and hard work. I am very happy and a lot smarter now. I think I might be in love with wireshark. I am definitely in love with NoScript and NotScript!
Marking thread solved.
]]>The pcap has two HTTP GET requests to the actual drudgereport servers, one for the index (GET /) and one for /favicon.ico, which the browser generally does on it's own to try to get the site icon, if any.
Filter for drudgereport query used to get IP addresses for next filter:
dns.qry.name contains "drudgereport.com"
Filter for HTTP GET requests for the aforementioned drudgereport servers:
(ip.addr == 98.158.19.137 || ip.addr == 98.158.27.203) && http.request.method == GET
Now lets look at HTTP GET requests for NOT those servers:
!(ip.addr == 98.158.19.137 || ip.addr == 98.158.27.203) && http.request.method == GET
There are many. The first is at .9 seconds, and the last is at 23.18 seconds.
Now looking at just the page request for drudgeport:
tcp.stream eq 4
It starts at .44 seconds and the server closes its end of the socket at 3.01 seconds, but your client doesn't close its until 10.47 seconds. I find that odd. Furthermore, the request for the favicon isn't until 22.35 seconds. My guess is that your browser is waiting for things to finish first. The things I am guessing are to blame are probably somewhere in the many extra requests to third parties in the interim.
It looks like no images were downloaded from drudgereport, likely becuase your browser has cached them already, so that may (or may not) add to the delay when not cached.
I theorize that a bunch of external stuff (ads, scripts, etc) are slowing things down.
Here is my advice for futher testing and observation for you to do:
Test with firefox with the noscript extension, which allows one to allow and disallow scripts per host or domain. The default settings will block all scripts. See how long the page load takes. I am guessing it will be a short, just as we saw with curl, which only downloads the page's HTML and nothing else.
If this is the case, and it's fast with scripts disabled, proceed to test by allowing one script domain one at a time and reloading until a slowness is apparent, and which point you can filter down the pcap to the secific host to observce and compare.
Or just leave scripts disabled with noscript.
This is a lot less of an answer and hopefully helpful troubleshooting advice. Why it would behave differently on the same machine with different OSes, I do not know.
]]>The file Arch-ChromeDrgRpt is a zero-byte file.
Tested by seperate download, I apologize for the error.
]]>It looks like neither of those new files I have permission to view.
Thanks, Fixed.
]]>It looks like neither of those new files I have permission to view.
]]>Assuming that it completed successfully, that took not long at all. I guess removing the -s option would be good for better visibility.
[ljohnson{09:14:07}~]$ time curl -o /dev/null http://www.drudgereport.com
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 43582 100 43582 0 0 215k 0 --:--:-- --:--:-- --:--:-- 370k
real 0m0.203s
user 0m0.007s
sys 0m0.000s
[ljohnson{09:14:23}~]$
I thought only certain sites were having slow load issues, like drudgereport.com.
I don't think starting with analyzing an 8 tab start-up is a very good idea. Generally when we troubleshoot a network or technical issue, it's best to start with the absolute minimum to reproduce the issue.
A pcap of an 8-tab start-up is not very helpful in that regard.
⋯ ⋯
If you want to get another pcap of only a single page loading slow, preferably drudge report, it would be a lot easier to analyze.
Here is boot chrome drudgereport only. Arch-ChromeDrgRpt
For comparison, here is WinXP x64 chrome *32 drudgereport only. WinXP-ChromeDrgRpt.zipx
I really appreciate your help!
I always start my Internet browsing sessions by opening these 8 tabs. That and ignorance are why I did the 8 tab capture.
Chrome is my preferred browser. I also use Firefox (slightly faster) and (faster with turbo but unstable).
I have taken the draconian step of using WinXP x64 for browsing tasks, faster even though rebooting is annoying.
]]>gsgleason wrote:Oh, and curl is very simple and would seriously only take you a moment to try that command. For example:
$ time curl -s -o /dev/null http://www.drudgereport.com real 0m3.406s user 0m0.187s sys 0m0.094s
If you don't want to follow the advice of those who are trying to help, that is of course your choice.
[ljohnson{07:29:23}~]$ time curl -s -o /dev/null http://www.drudgereport.com
real 0m0.665s
user 0m0.003s
sys 0m0.007sMore, later...
Assuming that it completed successfully, that took not long at all. I guess removing the -s option would be good for better visibility.
]]>Oh, and curl is very simple and would seriously only take you a moment to try that command. For example:
$ time curl -s -o /dev/null http://www.drudgereport.com real 0m3.406s user 0m0.187s sys 0m0.094s
If you don't want to follow the advice of those who are trying to help, that is of course your choice.
[ljohnson{07:29:23}~]$ time curl -s -o /dev/null http://www.drudgereport.com
real 0m0.665s
user 0m0.003s
sys 0m0.007s
More, later...
]]>$ time curl -s -o /dev/null http://www.drudgereport.com
real 0m3.406s
user 0m0.187s
sys 0m0.094s
If you don't want to follow the advice of those who are trying to help, that is of course your choice.
]]>I don't think starting with analyzing an 8 tab startup is a very good idea. Generally when we troubleshoot a network or technical issue, it's best to start with the absolute minumum to reproduce the issue.
A pcap of an 8-tab startup is not very helpful in that regard.
I filtered down to just things related to the drudge report with the following filter on the Arch-Chrome1stOpen file.
(dns.qry.name contains "drudge") or (ip.addr == 98.158.19.137) or (ip.addr == 98.158.27.203)
The first issue I see is that it took two attempts to initiate the TCP socket.
There was a TCP SYN sent at 23.02 seconds, then again at 24.02. Likely caused by internet congestion, but adding one second nonetheless.
The whole page, from initial DNS query to all the data being recieved, started at 23.03 seconds and ended at 24.17 seconds.
What's interesting is that your user agent doesn't close its end of the socket until 34.11 seconds.
I see that there is a lot of external scripting involved on that site, so possibly one or more of those is causing delays. I really don't have time to try to filter down to only the relevant data among 8 other tabs with of packets, though.
If you want to get another pcap of only a single page loading slow, preferably drudge report, it would be a lot easier to analyze.
]]>I am all for wireshark. I use it almost every day and find is useful. If you are okay with it, feel free to post a pcap.
Thanks.
Here's the current situation⋯
I have switched to Opera 12.02 with "Turbo Mode" enabled, and load/refresh times are much more reasonable.
Here is what I have posted (on my docs.google.com page)…
1) Wireshark output for a load of 8 tabs (my initial startup) for chrome on archlinux (zipped). It's a 6+MB file.
2) Wireshark output for a load of 8 tabs (my initial startup) for opera on archlinux (zipped). 2.8MB file.
3) I also ran the same on Vista 64 Ultimate/Chrome... 2.1 MB file
All these are run on the same hardware/LAN/router-firewall/cable-modem.
For arch, the nameservers are 209.213.196.218, 4.2.2.1, 216.52.1.1. For Vista they default to ISP nameservers (comcast).
Filter on Arch was to & from 192.168.0.5, host IP.
No filter on Win64 with 192.168.0.3 shutdown (32bit workstation)
I am very new to wireshark (& network administration), a veritable babe in the woods. If there is an oops or an anomaly in my running them, let me know, no problem to rerun, &c.
Thanks again, I hope something useful will come from all this work. I'm going to wait a bit before trying curl.
]]>